Skip to content

PyMutex failure in parking_lot.c on Windows during interpreter shutdown #135099

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

Closed
colesbury opened this issue Jun 3, 2025 · 2 comments
Closed
Labels
3.14 bugs and security fixes 3.15 new features, bugs and security fixes type-bug An unexpected behavior, bug, or error

Comments

@colesbury
Copy link
Contributor

colesbury commented Jun 3, 2025

Bug report

Bug description:

Fatal Python error: _PySemaphore_PlatformWait: unexpected error from semaphore: 4294967295 (error: 6)
Python runtime state: finalizing (tstate=0x6aa6c460)

Thread 0x00001360 (most recent call first):
  <no Python frame>
Windows fatal exception: code 0x80000003

Current thread 0x00001360 (most recent call first):
  <no Python frame>

Current thread's C stack trace (most recent call first):
  <cannot get C stack on this system>

4294967295 is the -1 return code from WaitForMultipleObjects. Error code 6 is ERROR_INVALID_HANDLE.

I'm pretty sure that the _PyOS_SigintEvent() handle is getting closed concurrently with the mutex wait.

HANDLE sigint_event = _PyOS_SigintEvent();
HANDLE handles[2] = { sema->platform_sem, sigint_event };
DWORD count = sigint_event != NULL ? 2 : 1;
wait = WaitForMultipleObjects(count, handles, FALSE, millis);
if (wait == WAIT_OBJECT_0) {
res = Py_PARK_OK;
}
else if (wait == WAIT_OBJECT_0 + 1) {
ResetEvent(sigint_event);
res = Py_PARK_INTR;
}
else if (wait == WAIT_TIMEOUT) {
res = Py_PARK_TIMEOUT;
}
else {
_Py_FatalErrorFormat(__func__,
"unexpected error from semaphore: %u (error: %u)",
wait, GetLastError());
}

Seen in https://github.com/python/cpython/actions/runs/15423887404/job/43405853684 at the end of running test_decorators.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Windows

Linked PRs

@colesbury colesbury added the type-bug An unexpected behavior, bug, or error label Jun 3, 2025
@colesbury colesbury changed the title PyMutex failure in parking_lot.c on Windows during interpreter shutdown PyMutex failure in parking_lot.c on Windows during interpreter shutdown Jun 3, 2025
@colesbury colesbury added 3.14 bugs and security fixes 3.15 new features, bugs and security fixes labels Jun 3, 2025
colesbury added a commit to colesbury/cpython that referenced this issue Jun 3, 2025
On Windows, the `_PyOS_SigintEvent()` event handle is used to interrupt
the main thread when Ctrl-C is pressed. Previously, we also waited on
the event from other threads, but ignored the result. However, this can
race with interpreter shutdown because the main thread closes the handle
in `_PySignal_Fini` and threads may still be running and using mutexes
during interpreter shtudown.

Only use `_PyOS_SigintEvent()` in the main thread in parking_lot.c, like
we do in other places in the CPython codebase.
@encukou
Copy link
Member

encukou commented Jun 3, 2025

Since #134747 ("Change PyThread_allocate_lock() implementation to PyMutex") was merged, Windows tests got really flaky, with several tests failing in each buildbot run with the same error:

Fatal Python error: _PySemaphore_PlatformWait: unexpected error from semaphore: 4294967295 (error: 6)
Python runtime state: finalizing (tstate=0x00007ff9a3c4aac8)
Thread 0x000023c8 (most recent call first):
  <no Python frame>
Windows fatal exception: code 0x80000003

For example, here: https://buildbot.python.org/#/builders/146/builds/11597/steps/5/logs/stdio

Currently at the release status page, on several Windows buildbots you can see a point where they "switched" from mostly-green to consistent "warnings" result; on the few I explored the first "yellow" build was for #134747.

Do you think that's related?

@colesbury
Copy link
Contributor Author

Yes, I think it's related

encukou pushed a commit that referenced this issue Jun 4, 2025
On Windows, the `_PyOS_SigintEvent()` event handle is used to interrupt
the main thread when Ctrl-C is pressed. Previously, we also waited on
the event from other threads, but ignored the result. However, this can
race with interpreter shutdown because the main thread closes the handle
in `_PySignal_Fini` and threads may still be running and using mutexes
during interpreter shtudown.

Only use `_PyOS_SigintEvent()` in the main thread in parking_lot.c, like
we do in other places in the CPython codebase.
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Jun 4, 2025
…ythonGH-135100)

On Windows, the `_PyOS_SigintEvent()` event handle is used to interrupt
the main thread when Ctrl-C is pressed. Previously, we also waited on
the event from other threads, but ignored the result. However, this can
race with interpreter shutdown because the main thread closes the handle
in `_PySignal_Fini` and threads may still be running and using mutexes
during interpreter shtudown.

Only use `_PyOS_SigintEvent()` in the main thread in parking_lot.c, like
we do in other places in the CPython codebase.
(cherry picked from commit cc581f3)

Co-authored-by: Sam Gross <[email protected]>
colesbury added a commit that referenced this issue Jun 4, 2025
…H-135100) (GH-135116)

On Windows, the `_PyOS_SigintEvent()` event handle is used to interrupt
the main thread when Ctrl-C is pressed. Previously, we also waited on
the event from other threads, but ignored the result. However, this can
race with interpreter shutdown because the main thread closes the handle
in `_PySignal_Fini` and threads may still be running and using mutexes
during interpreter shtudown.

Only use `_PyOS_SigintEvent()` in the main thread in parking_lot.c, like
we do in other places in the CPython codebase.
(cherry picked from commit cc581f3)

Co-authored-by: Sam Gross <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.14 bugs and security fixes 3.15 new features, bugs and security fixes type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

2 participants