]> git.ipfire.org Git - thirdparty/Python/cpython.git/commit
[3.14] gh-137433: Fix deadlock with stop-the-world and daemon threads (gh-137735...
authorMiss Islington (bot) <31488909+miss-islington@users.noreply.github.com>
Tue, 7 Oct 2025 18:46:52 +0000 (20:46 +0200)
committerGitHub <noreply@github.com>
Tue, 7 Oct 2025 18:46:52 +0000 (20:46 +0200)
commite09f33e5bf21c68fd4b214a21240381cc2df0a7b
tree953623fa03859c4f6bc9a61ffeb4aae5ef88f657
parentdb8b943259a43ee36840f9906f5e9bc8172d779d
[3.14] gh-137433: Fix deadlock with stop-the-world and daemon threads (gh-137735) (GH-138965)

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 commit 90fe3250f82712b61630d636246c92df7c40c816)

Co-authored-by: Sam Gross <colesbury@gmail.com>
Lib/test/test_threading.py
Misc/NEWS.d/next/Core_and_Builtins/2025-08-13-13-39-02.gh-issue-137433.g6Atfz.rst [new file with mode: 0644]
Python/parking_lot.c
Python/pystate.c