8000 gh-87135: threading.Lock: Raise rather than hang on Python finalization by encukou · Pull Request #135991 · python/cpython · GitHub
[go: up one dir, main page]

Skip to content

gh-87135: threading.Lock: Raise rather than hang on Python finalization #135991

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

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 8 additions & 1 deletion Doc/library/exceptions.rst
Original file line number Diff line number Diff line change
Expand Up @@ -429,7 +429,9 @@ The following exceptions are the exceptions that are usually raised.

* Creating a new Python thread.
* :meth:`Joining <threading.Thread.join>` a running daemon thread.
* :func:`os.fork`.
* :func:`os.fork`,
* acquiring a lock such as :class:`threading.Lock`, when it is known that
the operation would otherwise deadlock.

See also the :func:`sys.is_finalizing` function.

Expand All @@ -440,6 +442,11 @@ The following exceptions are the exceptions that are usually raised.

:meth:`threading.Thread.join` can now raise this exception.

.. versionchanged:: next

This exception may be raised when acquiring :meth:`threading.Lock`
or :meth:`threading.RLock`.

.. exception:: RecursionError

This exception is derived from :exc:`RuntimeError`. It is raised when the
Expand Down
5 changes: 5 additions & 0 deletions Include/internal/pycore_lock.h
Original file line number Diff line number Diff line change
Expand Up @@ -51,6 +51,11 @@ typedef enum _PyLockFlags {

// Fail if interrupted by a signal while waiting on the lock.
_PY_FAIL_IF_INTERRUPTED = 4,

// Locking & unlocking this lock requires attached thread state.
// If locking returns PY_LOCK_FAILURE, a Python exception *may* be raised.
// (Intended for use with _PY_LOCK_HANDLE_SIGNALS and _PY_LOCK_DETACH.)
_PY_LOCK_PYTHONLOCK = 8,
} _PyLockFlags;

// Lock a mutex with an optional timeout and additional options. See
Expand Down
55 changes: 55 additions & 0 deletions Lib/test/test_threading.py
Original file line number Diff line number Diff line change
Expand Up @@ -1247,6 +1247,61 @@ def __del__(self):
self.assertEqual(err, b"")
self.assertIn(b"all clear", out)

@support.subTests('lock_class_name', ['Lock', 'RLock'])
def test_acquire_daemon_thread_lock_in_finalization(self, lock_class_name):
# gh-123940: Py_Finalize() prevents other threads from running Python
# code (and so, releasing locks), so acquiring a locked lock can not
# succeed.
# We raise an exception rather than hang.
code = textwrap.dedent(f"""
import threading
import time

thread_started_event = threading.Event()

lock = threading.{lock_class_name}()
def loop():
if {lock_class_name!r} == 'RLock':
lock.acquire()
with lock:
thread_started_event.set()
while True:
time.sleep(1)

uncontested_lock = threading.{lock_class_name}()

class Cycle:
def __init__(self):
self.self_ref = self
self.thr = threading.Thread(
target=loop, daemon=True)
self.thr.start()
thread_started_event.wait()

def __del__(self):
assert self.thr.is_alive()

# We *can* acquire an unlocked lock
uncontested_lock.acquire()
if {lock_class_name!r} == 'RLock':
uncontested_lock.acquire()

# Acquiring a locked one fails
try:
lock.acquire()
except PythonFinalizationError:
assert self.thr.is_alive()
print('got the correct exception!')

# Cycle holds a reference to itself, which ensures it is
# cleaned up during the GC that runs after daemon threads
# have been forced to exit during finalization.
Cycle()
""")
rc, out, err = assert_python_ok("-c", code)
self.assertEqual(err, b"")
self.assertIn(b"got the correct exception", out)

def test_start_new_thread_failed(self):
# gh-109746: if Python fails to start newly created thread
# due to failure of underlying PyThread_start_new_thread() call,
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
Acquiring a :class:`threading.Lock` or :class:`threading.RLock` at interpreter
shutdown will raise :exc:`PythonFinalizationError` if Python can determine
that it would otherwise deadlock.
18 changes: 14 additions & 4 deletions Modules/_threadmodule.c
Original file line number Diff line number Diff line change
Expand Up @@ -834,9 +834,14 @@ lock_PyThread_acquire_lock(PyObject *op, PyObject *args, PyObject *kwds)
return NULL;
}

PyLockStatus r = _PyMutex_LockTimed(&self->lock, timeout,
_PY_LOCK_HANDLE_SIGNALS | _PY_LOCK_DETACH);
PyLockStatus r = _PyMutex_LockTimed(
&self->lock, timeout,
_PY_LOCK_PYTHONLOCK | _PY_LOCK_HANDLE_SIGNALS | _PY_LOCK_DETACH);
if (r == PY_LOCK_INTR) {
assert(PyErr_Occurred());
return NULL;
}
if (r == PY_LOCK_FAILURE && PyErr_Occurred()) {
return NULL;
}

Expand Down Expand Up @@ -1054,9 +1059,14 @@ rlock_acquire(PyObject *op, PyObject *args, PyObject *kwds)
return NULL;
}

PyLockStatus r = _PyRecursiveMutex_LockTimed(&self->lock, timeout,
_PY_LOCK_HANDLE_SIGNALS | _PY_LOCK_DETACH);
PyLockStatus r = _PyRecursiveMutex_LockTimed(
&self->lock, timeout,
_PY_LOCK_PYTHONLOCK | _PY_LOCK_HANDLE_SIGNALS | _PY_LOCK_DETACH);
if (r == PY_LOCK_INTR) {
assert(PyErr_Occurred());
return NULL;
}
if (r == PY_LOCK_FAILURE && PyErr_Occurred()) {
return NULL;
}

Expand Down
12 changes: 12 additions & 0 deletions Python/lock.c
Original file line number Diff line number Diff line change
Expand Up @@ -95,6 +95,18 @@ _PyMutex_LockTimed(PyMutex *m, PyTime_t timeout, _PyLockFlags flags)
if (timeout == 0) {
return PY_LOCK_FAILURE;
}
if ((flags & _PY_LOCK_PYTHONLOCK) && Py_IsFinalizing()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first part of the condition here is checking if any of the bits of _PY_LOCK_PYTHONLOCK are set. In other words, it will pass even if only _PY_LOCK_DETACH is set from PyMutex_Lock().

It could be:

if ((flags & _PY_LOCK_PYTHONLOCK) == _PY_LOCK_PYTHONLOCK && Py_IsFinalizing()) {

But given that this is an easy mistake to make and hard to spot, I'd rather just have a separate bit for fail-on-finalization and check that individual bit here.

If we want a constant to combine those three bits, let's keep that constant it in _threadmodule.c.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤦

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Won't this be prone to TOCTOU issues? Py_IsFinalizing could pass, but once the thread state detaches in the parking lot, the interpreter is free to start finalizing. The parking lot will then hang the thread upon reattachment in _PySemaphore_Wait, right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No - this check is only relevant for the main thread (the one that performs Py_Finalize()) so there's no TOCTOU. There are two "hanging" threads behaviors that you may be confusing:

  1. Non-main threads, typically daemon threads (and occasionally other non-daemon threads), hang when they try to attach during Python finalization. This PR doesn't affect that behavior.
  2. The main thread, when performing finalization, may acquire threading.Lock/RLock called via destructors / GC. If those locks happen to be held by other (now hung) threads, then the shutdown would deadlock. This instead raises a Python exception.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, yeah, I was confusing it with that. But, you've mentioned before that acquiring Python locks in finalizers isn't safe regardless of finalization, because the GC might run in any code where the lock is held and deadlock while reacquiring i CBB2 t. Looking at the test case, I think that still applies. What's the use-case that this PR is fixing?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the catch! I was too elated to whittle this down to a (hopefully) nice small tweak... and forgot how bits work :/


Won't this be prone to TOCTOU issues?
What's the use-case that this PR is fixing?

Even if there was a TOCTOU, I think this PR would be useful.
In cases where an app sometimes hangs on shutdown, making it usually raise an exception instead means this case is easier to debug.
Acquiring Python locks in finalizers isn't safe, but a PythonFinalizationError is more likely to make people realize that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, thanks for clearing it up.

// At this phase of runtime shutdown, only the finalization thread
// can have attached thread state; others hang if they try
// attaching. And since operations on this lock requires attached
// thread state (_PY_LOCK_PYTHONLOCK), the finalization thread is
// running this code, and no other thread can unlock.
// Raise rather than hang. (_PY_LOCK_PYTHONLOCK allows raising
// exceptons.)
PyErr_SetString(PyExc_PythonFinalizationError,
"cannot acquire lock at interpreter finalization");
return PY_LOCK_FAILURE;
}

uint8_t newv = v;
if (!(v & _Py_HAS_PARKED)) {
Expand Down
Loading
0