[Python-Dev] update on memory leaks in 2.2

Fred L. Drake, Jr. fdrake@acm.org
Fri, 7 Dec 2001 13:01:36 -0500

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.


Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation