[Python-Dev] update on memory leaks in 2.2

[Guido van Rossum]

> Insure labels them as (paraphrasing) "memory still allocated at exit",
> distinct from memory leaked.  I think this is equivalent to Purify's
> "potentially leaked" and "leaked" memory respectively.

I don't think so.  Insure (uselessly) lists *all* memory that's still
allocated and reachable at exit.  Purify only reports certain blocks
(in this case they were a bunch of weak refs) as potentially leaked.
I'm not sure what makes them potentially leaked, but it must be a
stronger condition than "still exists at exit".  As Fred mentioned,
this may have to do with the weaklist free list implementation.

> Note that at least stringobject.c has a hook for clearing out all
> those interned strings at program shutdown time, which I added to
> clean up Insure's output.  When INTERN_STRINGS is defined, the extra
> function _Py_ReleaseInternedStrings() is defined.  Then, in
> Modules/main.c, in Py_Main(), if __INSURE__ is defined that function
> is called, so this memory doesn't show up in the report.
> 
> It may be worthwhile generalizing this approach, and adding it to
> other static long-lived data structures, simply as an aid to memory
> debugging.  As long as it isn't enabled by default, that should be
> fine.

Most types that have a custom free list already have a cleanup routine
that's always called by Py_Finalize(); the weakref free list is
lacking one.  The interned list is special because it's generally
unsafe to clear it out when Py_Finalize() might be followed by
Py_Initialize() again -- that's why it's only done when running
Insure++.

--Guido van Rossum (home page: http://www.python.org/~guido/)