En Thu, 20 Aug 2009 07:02:26 -0300, ashwin.u....@nokia.com
<ashwin.u....@nokia.com> escribió:
We are currently trying to identify and fix all the memory leaks by just
doing Py_Initialize-PyRun_SimpleFile(some simple script)-Py_Finalize and
found that there are around 70 malloc-ed blocks which are not freed. One
of the significant contributor to this number is the 'files' object in
ZipImporter. I am not able to identify the reason for this leak and was
wondering if anyone on this list would help me out here.
So, here goes :
Since we have a zip file in our sys.path, this object is initialized and
added to the zip_directory_cache dict during Py_Initialize. One point to
note here is that there is no DECREF on the 'files' object after adding
it to the zip_directory_cache dict.
When a module in a directory is imported(encoding.alias) then the
reference count of 'files' is increased. When this module is unloaded
during Py_Finalize-PyImport_Cleanup, the ref count of files object is
decremented properly. So at the end of Py_Finalize the files object
still has one reference count which is a result of it being an entry in
the zip_directory_cache.
I didn't read the source, but isn't that the expected behavior? If the
module is still referenced by zip_directory_cache, the reference count
must be 1 or more.
Maybe zip_directory_cache should be cleared at interpreter shutdown?
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
