Really Python leaks?

[Barry A. Warsaw]

>>>>> "AK" == Andrew Kuchling <akuchlin at mems-exchange.org> writes:

    AK> Actually that probably isn't too surprising.  Some of the C
    AK> code, particularly in module initializers, will allocate
    AK> memory for a dictionary or other structure, and then not free
    AK> it.  For earlier versions of Python, the developers had access
    AK> to a copy of Purify; I don't know if they still do.

For Py2.x, I've also used Insure++ since we now primarily develop on
Linux and Purify doesn't support Linux.  I seem to remember fixing a
bunch of leaks, e.g. in exceptions.c.  I'm waiting for the Insure++
6.0 release for Linux, which is due out RSN, so I expect to go through
the same exercise before Py2.2 final.

    AK> Fixing these leaks isn't a big priority, because usually the
    AK> interpreter will only be finalized before the program exits
    AK> anyway.  Still, if you can provide more information about
    AK> where the leaks occur, perhaps they can be fixed.

There are leaks and then there are leaks. :) I'm usually primarily
concerned with the type that are true C leaks of memory blocks, almost
always caused by missing DECREFs.  There are plenty of places where
blocks are allocated that live until the interpreter exits.  I
(usually) don't consider them leaks.  A good way to find a leak is to
create a loop test (e.g. around Py_Initialize()/Py_Finalize()) and
watch for memory growth.

-Barry