[Seb Bacon]
... Seeing as the suspect leaker contains code like:
other = Foo() other.reciprocal = self self.reciprocal = other
I fear the worst ;-)
...but my (naive?) reading of the documentation was that reference cycles are cleaned out by the garbage collector, *unless* they define a __del__ (which is not the case here). How am I wrong?
You're reading the docs correctly. It's not necessarily cycles directly involving Foo objects that causes Foo objects to leak, it can be instead that some other (non-Foo) objects in cycles can't be collected, from which the Foo objects are in turn reachable. When an object O can't be collected, then neither can any object reachable from O. gc.get_referrers() can be used to find objects that refer to a given Foo instance. It's also possible that a something S refers to a Foo instance where S doesn't participate in cyclic gc. Then any cycle containing S is immortal, regardless of whether __del__ methods are defined in the cycle, and also then gc.get_referrers() can't reveal S's existence. Sometimes such an S is in the Python core, or in Zope's C code, although the more recent the release the less likely that is (more & more kinds of objects have been added to cyclic gc over time). Are you sure that *only* Foo objects are leaking? It's pretty rare, when there's a leak, to see only one kind of object leaking.