[issue10363] Embedded python, handle (memory) leak

[Martin Dunschen]

Martin Dunschen <mdunschen at gmail.com> 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 <report at bugs.python.org>
<http://bugs.python.org/issue10363>
_______________________________________