[Python-Dev] Memory leak tracking

[Barry A. Warsaw]

>>>>> "GvR" == Guido van Rossum <guido@beopen.com> writes:

    GvR> I don't know what Barry found, but I suspect they are genuine
    GvR> cycles created during the exception initialization.  It's
    GvR> easy enough to create cycles, e.g. form module -> class ->
    GvR> function -> module, or module -> function -> module, when
    GvR> defining classes or functions.

    GvR> The new GC code is *intended* to clean up exactly such
    GvR> cycles!

I suspect this is exactly what's happening.  I'd have to spend more
time to know exactly what's happening, but this jives with the
observed behavior.  If so, the only thing we could do is try to break
the cycles manually at shutdown time and have the normal decrefs free
all the memory.

I'm not sure it's worth the effort.  1) it isn't much memory; 2) it
only leaks when gc is disabled; 3) it's a one time cost, not
e.g. a leak every time you spawn a thread.

That last is interesting, because I believe at least on Solaris, there
/is/ a leak for each new thread, but I haven't had time to find it
yet.  That one's worth tracking down.  For the others, it's actually
quite nice to see gc doing it's job!

Other than that, running the test suite, the current CVS seems to have
a very clean bill of health memory usage-wise.

-Barry