> 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/)
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