Message120919
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 |
|
Date |
User |
Action |
Args |
2010-11-10 14:44:39 | martind | set | recipients:
+ martind, skrah |
2010-11-10 14:44:39 | martind | set | messageid: <1289400279.7.0.0359982947027.issue10363@psf.upfronthosting.co.za> |
2010-11-10 14:42:47 | martind | link | issue10363 messages |
2010-11-10 14:42:47 | martind | create | |
|