STINNER Victor added the comment:
It's basically a duplicate of bpo-1635741.
--
resolution: -> duplicate
stage: test needed -> resolved
status: open -> closed
superseder: -> Py_Finalize() doesn't clear all Python objects at exit
___
Python
STINNER Victor added the comment:
Python doesn't clean everything at exit: see bpo-29881.
I just modified Py_Main() in bpo-32030 to clean a few more bytes (like
program_name): see pymain_free() in Modules/main.c.
--
___
Steve Dower added the comment:
I don't think the refleak handling would detect leaks across
PyInitialize/PyFinalize calls anyway.
Really, we probably just need to loop Initialize/Finalize a few hundred times
and measure the memory usage of the process before/after.
Nick Coghlan added the comment:
I think it's reasonable to keep this open if the problems can be reproduced
with the current 3.7 dev branch - while we've refactored a lot of things, we
haven't specifically gone memory leak hunting for the embedded case, and I'm
pretty
PJ Naughter added the comment:
OK, Thanks for the quick reply. I have just migrated my application from Python
3.3 to Python 3.6.3 and would not expect you to backport changes from the 3.7
development stream to the released stream. What I will do when I get a chance
is
Steve Dower added the comment:
Not sure how much we can do about this, but you may want to try with Python
3.7. Eric and Nick have been working on streamlining startup, which includes a
lot of work (thanks Eric!) to remove static variables.
Don't expect a fix in
New submission from PJ Naughter :
I would like to report memory leaks in Python 3.6.3 when embedded in a C++
Windows app. I have download the Python 3.6.3 code and compiled a debug version
of Python with my copy of Visual Studio 2017 Professional (have also confirmed
the