> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4