[Python-Dev] update on memory leaks in 2.2

[Guido van Rossum]

> Neal Norwitz's Purify writes:
>  >          PLK: 704 bytes potentially leaked in 16 blocks
>  >          This memory was allocated from:
>  >                malloc         [rtlib.o]
>  >                _PyObject_GC_New [gcmodule.c:832]
>  >                PyWeakref_NewRef [weakrefobject.c:37]
>  >                weakref_ref    [_weakref.c:73]
>  >                PyCFunction_Call [methodobject.c:101]
>  >                eval_frame     [ceval.c:1989]
>  >                PyEval_EvalCodeEx [ceval.c:2570]
>  >                function_call  [funcobject.c:374]
>  >                PyObject_Call  [abstract.c:1665]
>  >                instancemethod_call [classobject.c:2276]
>  >                PyObject_Call  [abstract.c:1665]
>  >                PyEval_CallObjectWithKeywords [ceval.c:3034]
>  >          Block of 44 bytes (16 times); last block at 0x18bf0a8
> 
>   Free'd weakref objects are stored in a free list, so it makes sense
> that these are labelled potential leaks.
>   We could either give up using a free list for these, or we could
> allocate blocks of these rather than allocating them individually.
> The latter would allow still better performance and would reduce the
> malloc overhead.  That change would be a higher risk than tossing the
> free list, and tossing it would be a higher risk than keeping it this
> close to the release.  But we're probably far enough away that any of
> the options (no free list, blocking allocation, and leaving it alone)
> are manageable.

Thanks for the explanation!  The simplest way to avoid the Purify
"potential leak" complaints then might be to add a way to explicitly
zap this free list at Py_Finalize() time, like we do with other custom
free lists.  That should be a post-2.2 feature.

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