Martin Dunschen <[email protected]> added the comment:
I have identified 5 cases where objects of type PyThread_type_lock are
allocated but never freed again:
import.c:
import_lock
pystate.c:
head_mutex
thread.c:
key_mutex
ceval.c:
interpreter_lock
zliblock.c:
zlib_lock
This leads to a handle leak on windows (PyThread_type_lock) is mapped to
PNRMUTEX, a structure that contains a HANDLE to an event, created by
CreateEvent, but never released with CloseHandle. As I can see it, common to
all thread implementations (in thread.c) is the PyThread_allocate_lock call for
the above locks, but it is not matched by a PyThread_free_lock. I can imagine
there are similar memory leaks in other thread implementations for different OS.
Additionally there is one directly created event in
timemodule.c
hInterruptEvent
And finally in
myreadline.c:
_PyOS_ReadmeLock
no matching PyThread_free_lock for the call to PyThread_allocate_lock.
All these memory or handle leaks could easily be fixed by using some C++ smart
pointer implementations without requiring any changes to the API for
embedding/extending python. On windows it requires some minor changes to allow
compiling thread.c and timemodule.c as C++ code.
I am happy to post my version here, for other more knowledgeable python
programmers to review them. I see my suggestions as a patch, but in an ideal
world a lot of the code in pythoncore could be reimplemented using proper C++.
Martin
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue10363>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
