You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Deletion of autoTSSkey during runtime finalization is not safe #131185
The autoTssKey is deleted during _PyRuntimeState_Fini by gilstate_tss_fini. This isn't safe because other threads may try calling PyGILState_Ensure() or PyGILState_GetThisThreadState() concurrently during shutdown.
Making it a thread-local sounds reasonable, but I think we also need to deal with NULL auto interpreter states in order to get PyGILState_Ensure fully working (as in, hanging the thread) post-finalization.
My other concern (which might be an issue regardless of autoTSSkey) is what happens to the thread state when the thread is hung. Does it just get leaked?
The process is about to exit, so anything you "leak" is going to disappear soon
The native thread will still be leaked
Any Python objects referenced by the thread's stack will be leaked. This is true regardless of whether we kill the thread via pthread_exit() or block it via PyThread_hang_thread().
The process is about to exit, so anything you "leak" is going to disappear soon
I'm thinking about embedders that don't necessarily exit after Py_Finalize, but yeah, I don't think it matters much either. I would assume that most embedders keep the runtime alive for the duration of their app as well.
Activity
ZeroIntensity commentedon Mar 13, 2025
Making it a thread-local sounds reasonable, but I think we also need to deal with
NULLauto interpreter states in order to getPyGILState_Ensurefully working (as in, hanging the thread) post-finalization.My other concern (which might be an issue regardless of
autoTSSkey) is what happens to the thread state when the thread is hung. Does it just get leaked?colesbury commentedon Mar 14, 2025
No, the thread state gets deleted:
cpython/Python/pystate.c
Line 3057 in ca7fd81
But I'm not really sure it matters because:
pthread_exit()or block it viaPyThread_hang_thread().ZeroIntensity commentedon Mar 14, 2025
I'm thinking about embedders that don't necessarily exit after
Py_Finalize, but yeah, I don't think it matters much either. I would assume that most embedders keep the runtime alive for the duration of their app as well.gh-131185: Use a proper thread-local for cached thread states (gh-132510
ericsnowcurrently commentedon May 21, 2025
The broader issue of unprotected runtime state at finalization is handled in gh-134307.
ericsnowcurrently commentedon May 21, 2025
Thanks for tackling this, @ZeroIntensity!
pythongh-131185: Use a proper thread-local for cached thread states (p…
pythongh-131185: Use a proper thread-local for cached thread states (p…
pythongh-131185: Use a proper thread-local for cached thread states (p…
pythongh-131185: Use a proper thread-local for cached thread states (p…
pythongh-131185: Use a proper thread-local for cached thread states (p…