-
-
Notifications
You must be signed in to change notification settings - Fork 31.8k
Race on _PyRuntime.signals.unhandled_keyboard_interrupt
when calling eval()
concurrently in free-threading mode
#128130
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
Comments
_PyRuntime.signals.unhandled_keyboard_interrupt
when calling eval()
concurrently in free-threading mode
I think there's a race condition here even in the default build where a concurrent |
Also seen when running
|
Use an atomic operation when setting `_PyRuntime.signals.unhandled_keyboard_interrupt`. We now only clear the variable at the start of `_PyRun_Main`, which is the same function where we check it. This avoids race conditions where previously another thread might call `run_eval_code_obj()` and erroneously clear the unhandled keyboard interrupt.
Use an atomic operation when setting `_PyRuntime.signals.unhandled_keyboard_interrupt`. We now only clear the variable at the start of `_PyRun_Main`, which is the same function where we check it. This avoids race conditions where previously another thread might call `run_eval_code_obj()` and erroneously clear the unhandled keyboard interrupt.
Use an atomic operation when setting `_PyRuntime.signals.unhandled_keyboard_interrupt`. We now only clear the variable at the start of `_PyRun_Main`, which is the same function where we check it. This avoids race conditions where previously another thread might call `run_eval_code_obj()` and erroneously clear the unhandled keyboard interrupt.
Closing, on the assumption the PR linked above fixed this! |
Not fixed on the 3.13 branch:
|
The PR was merged into main, but I didn't backport it to 3.13. I've been generally hesitant to backport PRs that primarily fix TSAN warnings as opposed to crashes or other user visible misbehavior. If it makes testing Jax easier, let me know and we can reconsider backporting the fix. |
It's not critical. It's just an entry in a tsan suppression file. Actually, we're doing pretty well overall. We're down to only 2 unfixed races in our test suite (#129748, #128050), assuming the things tagged as fixed in 3.14 are indeed fixed. |
Are you able to test with 3.14 as well? If not, what are the blockers? |
No blockers. We just don't have that test. We've done it manually a few times. Let me add that to our CI. |
Closing, we haven't seen this race under 3.14. |
Bug report
Bug description:
Run the following code under Python 3.13.1t with thread-sanitizer enabled:
Get:
I think
namedtuple
callseval()
, which triggers a race here:cpython/Python/pythonrun.c
Line 1318 in 0671451
CPython versions tested on:
3.13
Operating systems tested on:
Linux
Linked PRs
The text was updated successfully, but these errors were encountered: