-
-
Notifications
You must be signed in to change notification settings - Fork 30.6k
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
Crash running PyO3 tests with --test-threads=1000 #124375
Comments
Ok, I think I understand the problem. We loop over all the thread states in the free-threaded GC, calling cpython/Python/gc_free_threading.c Lines 427 to 433 in 41e7992
The problem is that the thread states might not yet be initialized, so |
…d states This fixes a crash when running the PyO3 test suite on the free-threaded build. The `qsbr` field is initialized after the `PyThreadState` is added to the interpreter's linked list -- it might still be NULL. Instead, we "steal" the queue of to-be-freed memory blocks. This is always initialized (possibly empty) and protected by the stop the world pause.
…es (#124459) This fixes a crash when running the PyO3 test suite on the free-threaded build. The `qsbr` field is initialized after the `PyThreadState` is added to the interpreter's linked list -- it might still be NULL. Instead, we "steal" the queue of to-be-freed memory blocks. This is always initialized (possibly empty) and protected by the stop the world pause.
…d states (pythonGH-124459) This fixes a crash when running the PyO3 test suite on the free-threaded build. The `qsbr` field is initialized after the `PyThreadState` is added to the interpreter's linked list -- it might still be NULL. Instead, we "steal" the queue of to-be-freed memory blocks. This is always initialized (possibly empty) and protected by the stop the world pause. (cherry picked from commit 54c6fcb) Co-authored-by: Sam Gross <[email protected]>
…ad states (GH-124459) (#125540) This fixes a crash when running the PyO3 test suite on the free-threaded build. The `qsbr` field is initialized after the `PyThreadState` is added to the interpreter's linked list -- it might still be NULL. Instead, we "steal" the queue of to-be-freed memory blocks. This is always initialized (possibly empty) and protected by the stop the world pause. (cherry picked from commit 54c6fcb) Co-authored-by: Sam Gross <[email protected]>
Crash report
What happened?
Unfortunately I don't know how to make this more minimal than "run the PyO3 tests".
You'll need rust 1.81 installed along with a copy of the latest version of PyO3 from github and a free-threaded Python interpreter.
Repeatedly run the PyO3 tests with
UNSAFE_PYO3_BUILD_FREE_THREADED=1 cargo test --lib -- --test-threads=1000
, and eventually you'll see a seg fault. If you run the test executable under a debugger, you'll see a C traceback like this, crashing on an atomic load inside the GC internals:Not sure if it will be helpful, but the tracebacks from all of the threads are here: https://gist.github.com/ngoldbaum/d3f5bceba9554ba8347c40773446b08d
Happy to help with reproducing this if anyone has trouble getting PyO3 setup. I'm on the CPython discord in the #free-threading channel if chatting is easier.
CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux, macOS
Output from running 'python -VV' on the command line:
Python 3.13.0rc2 experimental free-threading build (main, Sep 23 2024, 13:34:50) [Clang 15.0.0 (clang-1500.3.9.4)]
Linked PRs
_PyMem_ProcessDelayed
on other thread states #124459_PyMem_ProcessDelayed
on other thread states (GH-124459) #125540The text was updated successfully, but these errors were encountered: