_PySemaphore_Wakeup: parking_lot: ReleaseSemaphore failed

[A5rocks]

Crash report

What happened?

There might be a bunch of other code wrapping around this, and this doesn't always reproduce it.

Details

import trio
import signal
import threading

def run_in_trio_thread_ki_inner() -> None:
    # if we get a control-C during a run_in_trio_thread, then it propagates
    # back to the caller (slick!)
    record = set()

    async def check_run_in_trio_thread() -> None:
        token = trio.lowlevel.current_trio_token()

        def trio_thread_fn() -> None:
            print("in Trio thread")
            assert not trio.lowlevel.currently_ki_protected()
            print("ki_self")
            try:
                signal.raise_signal(signal.SIGINT)
            finally:
                import sys

                print("finally", sys.exc_info())

        async def trio_thread_afn() -> None:
            trio_thread_fn()

        def external_thread_fn() -> None:
            try:
                print("running")
                trio.from_thread.run_sync(trio_thread_fn, trio_token=token)
            except KeyboardInterrupt:
                print("ok1")
                record.add("ok1")
            try:
                trio.from_thread.run(trio_thread_afn, trio_token=token)
            except KeyboardInterrupt:
                print("ok2")
                record.add("ok2")

        thread = threading.Thread(target=external_thread_fn)
        thread.start()
        print("waiting")
        while thread.is_alive():  # noqa: ASYNC110
            await trio.sleep(0.01)  # Fine to poll in tests.
        print("waited, joining")
        thread.join()
        print("done")

    trio.run(check_run_in_trio_thread)
    assert record == {"ok1", "ok2"}

run_in_trio_thread_ki_inner()

Here's an example from logs: https://github.com/A5rocks/trio/actions/runs/24711139448/job/72275846322#step:4:1174 providing this stack trace:

Fatal Python error: _PySemaphore_Wakeup: parking_lot: ReleaseSemaphore failed
Python runtime state: initialized

Stack (most recent call first):
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Lib\site-packages\trio\_core\_io_windows.py", line 325 in _get_underlying_socket
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Lib\site-packages\trio\_core\_io_windows.py", line 360 in _get_base_socket
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Lib\site-packages\trio\_core\_io_windows.py", line 737 in _afd_poll
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Lib\site-packages\trio\_core\_io_windows.py", line 779 in wait_readable
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Lib\site-packages\trio\_core\_generated_io_windows.py", line 61 in wait_readable
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Lib\site-packages\trio\_core\_wakeup_socketpair.py", line 42 in wait_woken
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Lib\site-packages\trio\_core\_entry_queue.py", line 101 in task
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Lib\site-packages\trio\_core\_run.py", line 2867 in unrolled_run
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Lib\site-packages\trio\_core\_run.py", line 2533 in run
  File "D:\a\trio\trio\empty\repro.py", line 49 in run_in_trio_thread_ki_inner
  File "D:\a\trio\trio\empty\repro.py", line 52 in <module>
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Lib\site-packages\coverage\execfile.py", line 213 in run
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Lib\site-packages\coverage\cmdline.py", line 1042 in do_run
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Lib\site-packages\coverage\cmdline.py", line 853 in command_line
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Lib\site-packages\coverage\cmdline.py", line 1163 in main
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Scripts\coverage.exe\__main__.py", line 10 in <module>
  File "<frozen runpy>", line 88 in _run_code
  File "<frozen runpy>", line 198 in _run_module_as_main

Extension modules: _cffi_backend (total: 1)

Here's another example! https://github.com/A5rocks/trio/actions/runs/24711139448/job/72275846557#step:4:1225 with these logs:

Fatal Python error: _PySemaphore_Wakeup: parking_lot: ReleaseSemaphore failed
Python runtime state: initialized

Stack (most recent call first):
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Lib\site-packages\coverage\bytecode.py", line 83 in bytes_to_lines
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Lib\site-packages\coverage\sysmon.py", line 350 in sysmon_py_start
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Lib\site-packages\trio\_core\_run.py", line 2012 in task_exited
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Lib\site-packages\trio\_core\_run.py", line 2890 in unrolled_run
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Lib\site-packages\trio\_core\_run.py", line 2533 in run
  File "D:\a\trio\trio\empty\repro.py", line 49 in run_in_trio_thread_ki_inner
  File "D:\a\trio\trio\empty\repro.py", line 52 in <module>
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Lib\site-packages\coverage\execfile.py", line 213 in run
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Lib\site-packages\coverage\cmdline.py", line 1042 in do_run
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Lib\site-packages\coverage\cmdline.py", line 853 in command_line
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Lib\site-packages\coverage\cmdline.py", line 1163 in main
  File "C:\hostedtoolcache\windows\Python\3.14.4\x64-freethreaded\Scripts\coverage.exe\__main__.py", line 10 in <module>
  File "<frozen runpy>", line 88 in _run_code
  File "<frozen runpy>", line 198 in _run_module_as_main

Extension modules: _cffi_backend (total: 1)

Also note that this requires a) freethreading and b) specifically the Windows x64 build. (maybe this reproduces on other builds too, but I haven't seen it.)

CPython versions tested on:

3.14

Operating systems tested on:

No response

Output from running 'python -VV' on the command line:

No response

Linked PRs

• gh-148820: Fix _PyRawMutex use-after-free on spurious semaphore wakeup #148847
• gh-148820: Fix _PyRawMutex use-after-free on spurious semaphore wakeup #148852

[sergey-miryanov]

cc @colesbury @kumaraditya303

[kumaraditya303]

I have seen this error before, don't remember where but I think the root cause is that this is a Windows handle reuse issue. If the application creates a handle and uses it and that gets reused for a CPython semaphore then the application can accidentally close it which can cause this crash.

[colesbury]

To expand on what @kumaraditya303 wrote, it's usually because some application or library code closes the same HANDLE twice:

CloseHandle(h);
...
CloseHandle(h); // may close a random handle in your program!

If your application closes closes the same handle twice, the second attempt might do nothing or might close a random handle in your program, such as the handle used for _PySemaphore.

[ngoldbaum]

See gorakhargosh/watchdog#1132 (comment) for when this came up before.

[colesbury]

@A5rocks - have you seen this outside CI?

[A5rocks]

Not yet. I'll try to get my hands on a Windows machine soon (this will help me get a shorter iteration loop too! so that I can check all the CloseHandles).

[colesbury]

Also, does it repro without coverage? I took a look at your repo & CI and it wasn't clear to me

[A5rocks]

Yep, just tried that now! https://github.com/A5rocks/trio/actions/runs/24736426473

(it's just significantly rarer, so prior attempts just didn't run into it...)

[colesbury]

I think Claude Code found the bug and it's in CPython's _PyRawMutex_LockSlow. I will put up a PR soon. Thank you for the bug report and reproducer.