[Zope-dev] debugging memory leaks

[Tim Peters]

[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.