[issue10363] Embedded python, handle (memory) leak

Antoine Pitrou added the comment: Closing as the original issue is fixed. Other leaks should be reported as separate issues. -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker

[issue10363] Embedded python, handle (memory) leak

Roundup Robot added the comment: New changeset 608975eafe86 by Antoine Pitrou in branch '3.2': Issue #10363: Deallocate global locks in Py_Finalize(). http://hg.python.org/cpython/rev/608975eafe86 New changeset 728595c16acd by Antoine Pitrou in branch 'default': Issue #10363: Deallocate global

[issue10363] Embedded python, handle (memory) leak

Martin v. Löwis added the comment: As a policy, we will not rely on C++ destructors for cleanup. There are really two issues here: "global" locks, and module-specific locks. The global locks can and should be released in Py_Finalize, with no API change. Antoine's patch looks good to me. For

[issue10363] Embedded python, handle (memory) leak

Antoine Pitrou added the comment: > If the handle leaks are restricted to the windows implementation of cpython, > could it not be justified to allow C++ in a patch, I can't think of a C only > compiler for windows? Well, I think that would be rather clumsy. I'm not a Windows user myself, perh

[issue10363] Embedded python, handle (memory) leak

Martin Dunschen added the comment: Hello Antoine Unloading would not be necessary if the DLL is just the python interpreter, but if you build a DLL with python embedded that does quite a bit more than some python interpreting (in my case complex C/C++ numerical calculations) unloading the DLL i

[issue10363] Embedded python, handle (memory) leak

Antoine Pitrou added the comment: Here is a patch that fixes some of these handle leaks in Python 3.2. However, as a general guideline, you shouldn't unload the Python DLL if you fish to use it later again. Just keep it in memory (the DLL isn't very big, is it?). Yes, C++ would allow to solve

[issue10363] Embedded python, handle (memory) leak

Changes by Antoine Pitrou : -- nosy: +pitrou versions: +Python 3.2, Python 3.3 -Python 2.7 ___ Python tracker ___ ___ Python-bugs-list

[issue10363] Embedded python, handle (memory) leak

Changes by Steven Youngs : -- nosy: +StevenY ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue10363] Embedded python, handle (memory) leak

Martin Dunschen 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 ha

[issue10363] Embedded python, handle (memory) leak

Martin Dunschen added the comment: Here my suggested changes in plain text (I generated these as patches from a diff to the current code): thread.c: 353a354,359 > void PyThread_fini() > { > // should assert here that nkeys == 0 > PyThread_free_lock(keymutex); > } > pystate.c: 38

[issue10363] Embedded python, handle (memory) leak

Stefan Krah added the comment: I don't see a file attached. Could you attach your patches in plain text? It is the preferred method, since files can be easily viewed in the browser. -- nosy: +skrah ___ Python tracker

[issue10363] Embedded python, handle (memory) leak

Changes by Martin v. Löwis : -- versions: -Python 2.5, Python 2.6 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue10363] Embedded python, handle (memory) leak

New submission from Martin Dunschen : I found a number of 'handle leaks' in the core code to embed python into a C/C++ application on windows. To reproduce: The simplest possible embedded application only calls: #include void entry() { Py_Initialize(); Py_Finalize(); } I found (but