Seb Bacon wrote:
So, say Foo is leaking because it is referenced from O which can't be
collected. Given 100 things which refer to Foo, how do I identify which
one is O? And of course, then O may be leaking because it is referenced
from P...
I sense this question is a bit like asking someone t
Seb Bacon wrote:
So, say Foo is leaking because it is referenced from O which can't be
collected. Given 100 things which refer to Foo, how do I identify which
one is O? And of course, then O may be leaking because it is referenced
from P...
I've been looking into memory leaks of my own, and p
Tim Peters wrote:
[Seb Bacon]
...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
[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
Tim Peters wrote:
Debugging memory leaks can be hard, in any language.
No kidding. I thought when I identified the suspect class two days ago
I was nearly there ;-)
Another place to look
for ideas is in the top-level test.py from a current Zope HEAD checkout (or
2.7 branch, or Zope3).
OK, wi
[Seb Bacon]
> ...
> I know from the refcounts in Zope that items of class Foo are
> definitely leaking, yet when I do a sys.getobjects(0, Foo) I get
> nothing back.
If Foo is an old-style class, then every instance of Foo has type
InstanceType (and so does every instance of every other old-style c
