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
test_threading.test_interrupt_main_subthread
: release unlocked lock
#118433
Comments
I'm able to reproduce it locally ~3-8% of the time with a command like on Linux (x86-64) and macOS (arm64):
|
The bug is triggered because the Line 368 in 72dae53
I'm able to reproduce the issue reliably, including in the default build, with the following patch: https://gist.github.com/colesbury/74e2523c3622f479f7e39fc62c5dc948 |
@mpage I'd appreciate your thoughts on this since you've recently looked at related thread-safety issues. I'm not sure if there's a reliable fix without moving a lot of the |
I'm not sure what the right thing to do here is. I think the fundamental challenge is that we need to make
|
Reminds me of trio's KeyboardInterrupt protection, with an 2017 blog post. |
@encukou - thanks for the link, that sounds like the same issue. Marking the frame is tricky because the |
So I think the options we've come up with are:
Either approach seems reasonable to me. What do both of you think? EDIT: trio changes the signal handler, but that seems less appropriate in CPython than option 2. |
Free-threaded builds can intermittently tickle a longstanding bug (24 years!) in the implementation of `threading.Condition`, leading to flakiness in the test suite. Fixing the underlying issue will require more discussion, and will likely apply to most of the concurrency primitives in the `threading` module that are written in Python. See pythongh-118433 for more details. Disable the test in free-threaded builds as a temporary measure to eliminate flakiness.
…hreaded builds (#118485) Free-threaded builds can intermittently tickle a longstanding bug (24 years!) in the implementation of `threading.Condition`, leading to flakiness in the test suite. Fixing the underlying issue will require more discussion, and will likely apply to most of the concurrency primitives in the `threading` module that are written in Python. See gh-118433 for more details.
Recording the gist of my conversation with @colesbury. If we can make it work, I think option (2) is preferable, for a few reasons:
|
I don't think I'll have time to have a proper look at this before beta, so a few quick comments:
I guess, that would need to be inlined (that is, always set in
AFAIK, this just trio doing whatever it can from Python code -- if it could do something like disable some of the eval breaker, it'd do that instead.
Yup, that's why I'd look at what works for trio :) |
…free-threaded builds (python#118485) Free-threaded builds can intermittently tickle a longstanding bug (24 years!) in the implementation of `threading.Condition`, leading to flakiness in the test suite. Fixing the underlying issue will require more discussion, and will likely apply to most of the concurrency primitives in the `threading` module that are written in Python. See pythongh-118433 for more details.
@Zac-HD, you might be interested in this issue |
I'm vaguely familiar with Trio's attempts to solve this, but if you've already read the blog post above I don't think I'd have much more to add. "Arbitrary Python code' in a |
Bug report
Seen on the ARM64 macOS nogil refleaks buildbot:
https://buildbot.python.org/all/#/builders/1368/builds/865/steps/5/logs/stdio
Reported by encoku
Linked PRs
test_interrupt_main_subthread
in free-threaded builds #118485The text was updated successfully, but these errors were encountered: