NotificationsYou must be signed in to change notification settings
Fork33.3k
Star69.7k

[3.14] gh-137433: Fix deadlock with stop-the-world and daemon threads (gh-137735)#138965

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Jump to bottom

Merged

encukou merged 3 commits intopython:3.14frommiss-islington:backport-90fe325-3.14

Oct 7, 2025

Merged

[3.14] gh-137433: Fix deadlock with stop-the-world and daemon threads (gh-137735)#138965

encukou merged 3 commits intopython:3.14frommiss-islington:backport-90fe325-3.14

Oct 7, 2025

Conversation

Copy link

Contributor

miss-islington commentedSep 16, 2025•
edited by bedevere-appbot
Loading

There was a deadlock originally seen by Memray when a daemon thread
enabled or disabled profiling while the interpreter was shutting down.
I think this could also happen with garbage collection, but I haven't
seen that in practice.

The daemon thread could be hung while trying acquire the global rwmutex
that prevents overlapping global and per-interpreter stop-the-world events.
Since it already held the main interpreter's stop-the-world lock, it
also deadlocked the main thread, which is trying to perform interpreter
finalization.

Swap the order of lock acquisition to prevent this deadlock.
Additionally, refactor_PyParkingLot_Park so that the global buckets
hashtable is left in a clean state if the thread is hung in
PyEval_AcquireThread.
(cherry picked from commit90fe325)

Co-authored-by: Sam Grosscolesbury@gmail.com

Issue:Deadlock at shutdown with stop-the-world and daemon threads #137433

pythongh-137433: Fix deadlock with stop-the-world and daemon threads (p…

50ac0c0

…ythongh-137735)There was a deadlock originally seen by Memray when a daemon threadenabled or disabled profiling while the interpreter was shutting down.I think this could also happen with garbage collection, but I haven'tseen that in practice.The daemon thread could be hung while trying acquire the global rwmutexthat prevents overlapping global and per-interpreter stop-the-world events.Since it already held the main interpreter's stop-the-world lock, italso deadlocked the main thread, which is trying to perform interpreterfinalization.Swap the order of lock acquisition to prevent this deadlock.Additionally, refactor `_PyParkingLot_Park` so that the global bucketshashtable is left in a clean state if the thread is hung in`PyEval_AcquireThread`.(cherry picked from commit90fe325)Co-authored-by: Sam Gross <colesbury@gmail.com>