-
-
Notifications
You must be signed in to change notification settings - Fork 30.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PyThreadState
and PyInterpreterState
are not freed
#99205
Comments
Seems related to the 3.11 new frame handling. |
I can reproduce this. At first glance, I'm not certain that its related to the frame stuff: debugging seems to confirm that the allocations and deallocations of stack chunks are balanced, and the issue is present even when changing which allocator we use, etc. Plus, the leaked memory per thread (~370 bytes) seems too small to be our 16KB chunks. It's almost exactly |
Found it... we don't free the memory if the thread state's Lines 754 to 760 in 2eee9d9
It appears we're not setting it correctly. We initialize each thread by Lines 847 to 850 in 2eee9d9
cpython/Include/internal/pycore_runtime_init.h Lines 65 to 70 in 2eee9d9
So I think the fix is just to make sure that new threads have @ericsnowcurrently: is my understanding correct? I can write a patch, if so. |
Also, it looks like |
I want to agree, but something seems off. I'll have to take a look tomorrow. |
Confirmed that setting |
PyThreadState
and PyInterpreterState
are not freed
It might be useful to define APIs to copy a PyInterpreterState and PyThreadStats where all of this can be encapsulated? granted there seems to be only one place in the code that is doing this right now so... |
Having looked over the code again, I agree that The same applies for (What threw me off last night is that we |
Thinking about this more, we could even get rid of the |
So you mean check |
…onGH-99268) (cherry picked from commit 283ab0e) Co-authored-by: Brandt Bucher <brandtbucher@microsoft.com>
Fixed, but leaving open to track the above discussion. |
Right, that's what I was thinking, it would make this more obvious when it is statically allocated and yes static allocation only makes sense for main interpreter and thread. |
A memleak was found in cpython 3.11.0 that looks to potentially be reasonably serious Upstream issue is python/cpython#99205 This uses the merged upstream patch python/cpython#99301 until we bump to a newer release (3.11.1+)
* main: (8272 commits) Update Windows readme.txt to clarify Visual Studio required versions (pythonGH-99522) pythongh-99460 Emscripten trampolines on optimized METH_O and METH_NOARGS code paths (python#99461) pythongh-92647: [Enum] use final status to determine lookup or create (pythonGH-99500) pythongh-81057: Move Globals in Core Code to _PyRuntimeState (pythongh-99496) Post 3.12.0a2 pythongh-99300: Use Py_NewRef() in Python/Python-ast.c (python#99499) pythongh-93649: Split pytime and datetime tests from _testcapimodule.c (python#99494) pythongh-99370: fix test_zippath_from_non_installed_posix (pythonGH-99483) pythonGH-99205: remove `_static` field from `PyThreadState` and `PyInterpreterState` (pythonGH-99385) pythongh-81057: Move the Remaining Import State Globals to _PyRuntimeState (pythongh-99488) pythongh-87604: Avoid publishing list of active per-interpreter audit hooks via the gc module (pythonGH-99373) pythongh-93649: Split getargs tests from _testcapimodule.c (python#99346) pythongh-81057: Move Global Variables Holding Objects to _PyRuntimeState. (pythongh-99487) pythonGH-98219: reduce sleep time in `asyncio` subprocess test (python#99464) pythonGH-99388: add `loop_factory` parameter to `asyncio.run` (python#99462) pythongh-99300: Use Py_NewRef() in PC/ directory (python#99479) pythongh-99300: Use Py_NewRef() in Doc/ directory (python#99480) pythongh-99300: Use Py_NewRef() in Modules/ directory (python#99473) pythongh-99300: Use Py_NewRef() in Modules/ directory (python#99469) pythongh-99370: Calculate zip path from prefix when in a venv (pythonGH-99371) ...
Py 3.11 is released so I assume we can remove "rc" qualifiers here aiosqlite is causing python 3.11 crashes, so I assume this is due to python/cpython#99205. I'm only guessing the syntax here, so there may be subsequent commits if this doesnt work Change-Id: I6f2ead3e0aca933a972efadf3891edbcdd83501c
I just spent half a day looking for sources of memleaks in py3.11 provided by Ubuntu (22.04 provides python3.11 package containing As a sidenote, in my case problem appeared in code which embeds python and uses
leaked 20 objects of 360 bytes each. Switching number threads to 50 made it leak 50 such objects, etc. ASAN attributed those objecs to |
The following test program gains about 10M per second under top, on Python 3.11 only (confirmed for all development stages: 3.11.0a4, 3.11.0b1, 3.11.0rc1, 3.11.0) . 3.10 shows no memory growth.
For direct results, here's the same program using the
resource
module that I just saw used over at #98467:The above program under Py 3.11.0 prints:
under Python 3.10 it prints:
the issue looks extremely similar to another one we just fixed in greenlet, over at python-greenlet/greenlet#328, although this one is much more surprising. Issue #98467 might also be related.
Environment:
_static
field fromPyThreadState
andPyInterpreterState
#99385The text was updated successfully, but these errors were encountered: