[Python-Dev] update on memory leaks in 2.2 (original) (raw)

Guido van Rossum guido@python.org
Fri, 07 Dec 2001 12:28:15 -0500

Neal Norwitz's Purify writes: > PLK: 704 bytes potentially leaked in 16 blocks > This memory was allocated from: > malloc [rtlib.o] > PyObjectGCNew [gcmodule.c:832] > PyWeakrefNewRef [weakrefobject.c:37] > weakrefref [weakref.c:73] > PyCFunctionCall [methodobject.c:101] > evalframe [ceval.c:1989] > PyEvalEvalCodeEx [ceval.c:2570] > functioncall [funcobject.c:374] > PyObjectCall [abstract.c:1665] > instancemethodcall [classobject.c:2276] > PyObjectCall [abstract.c:1665] > PyEvalCallObjectWithKeywords [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/)