]> git.ipfire.org Git - thirdparty/Python/cpython.git/commit
gh-137433: Fix deadlock with stop-the-world and daemon threads (gh-137735)
authorSam Gross <colesbury@gmail.com>
Tue, 16 Sep 2025 08:21:58 +0000 (09:21 +0100)
committerGitHub <noreply@github.com>
Tue, 16 Sep 2025 08:21:58 +0000 (09:21 +0100)
commit90fe3250f82712b61630d636246c92df7c40c816
treefda5744e66c405f20bed9efa6d2e5a6df76654dc
parent4c0d7bc52afcd6b34b1085a52bb33ae695f656e5
gh-137433: Fix deadlock with stop-the-world and daemon threads (gh-137735)

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`.
Include/internal/pycore_semaphore.h
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/lock.c
Python/parking_lot.c
Python/pystate.c