On Thursday, Aug 7, 2003, at 14:08 Europe/London, Michael Hudson wrote:
Since Zope has worse leak problems than Python, Zope testing has more tools to dig into it:
That's the Zope3 unittest test driver. The TrackRefs class is a handy little beast, which uses a debug build's sys.getobjects() to keep track of how many objects of each *type* exist across test runs, and how many refcounts total they account for. After the first few iterations, TrackRefs doesn't itself distort the results it prints. It will tell you the types of the objects that are leaking, and also whether objects are actually leaking, or that merely refcounts to existing objects are leaking (e.g., a common kind of "leak" is to forget to decref Py_None, but memory doesn't actually grow then).
[I'll observe that trying to wrap running a test in a refcount neutral way is entertaining...]
Cool! I'd blundered my way to something like an ad hoc version of this, next time I'll use something that someone's actually thought about :-)
OK, so I've now blundered my way to the attached, which when run produces this:
ints seems to leak 1 references... <type 'long'> 1 4 multi seems to leak 9 references... <type 'tuple'> 1 5 <type 'classobj'> 1 4 <type 'dict'> 1 4 <type 'int'> 1 3 <type 'str'> 0 4 <type 'NoneType'> 0 1 slots seems to leak 10 references... <type 'tuple'> 5 20 <type 'type'> 0 5 errors seems to leak 9 references... <type 'tuple'> 4 16 <type 'type'> 0 5 subtype_resurrection seems to leak 2 references...
(the names are all names of functions in test_descr).
I might have a look at these over the next few days (and also might ponder other bits of the test suite).