Repository navigation
Conversation
Since JuliaLang/julia#61341, the macOS exception handler that parks a thread at a GC safepoint identifies the faulting thread by its pthread id, without skipping threads that have exited. A foreign thread that reuses the id of one that exited is then matched to the dead entry and resumed instead of parked, so the collector waits for it forever (JuliaLang/julia#63893). The test that collects while a driver thread waits for a completion's lock triggers exactly that: an earlier test's foreign thread has exited, and the new one spins on the lock, hitting safepoints while `GC.gc()` runs. This made the macOS nightly job hang until it was cancelled. Skip that test on affected versions until the runtime is fixed.
maleadt
force-pushed
the
tb/mach-safepoint-hang
branch
from
October 17, 2026 09:41
677950f to
6088878
Compare
Member
Author
|
May not need this if JuliaLang/julia#63898 lands |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The macOS nightly job has hung on every run since #27, until GitHub cancelled it after six hours.
The hang is a Julia regression, not a bug in the package. Since JuliaLang/julia#61341 (1.14 only, not in 1.13), the macOS exception handler that parks a thread at a GC safepoint identifies the faulting thread by its pthread id, without skipping threads that have exited (the check from JuliaLang/julia#50871 was dropped). Exited threads stay in
jl_all_tls_statesforever, and macOS reuses pthread ids, so a new foreign thread with the id of an exited one is matched to the dead entry, whosecurrent_taskisNULL. The trampoline then resumes it instead of parking it, andjl_gc_wait_for_the_worldwaits forever while the thread bounces through the handler.The "completion lock" test added in #27 triggers exactly that on purpose: it collects while a driver thread spins on a completion's lock, and the foreign thread from the preceding test has just exited. Reproduced on an M1 with the same nightly as CI (1.14.0-DEV.3752); the
cooperative_waittestset passes and the process hangs in that test with the main thread injl_gc_wait_for_the_world. A pure-Julia reproducer (no GPUToolbox) hangs on nightly only when a foreign thread exited first, and passes on 1.12.This skips that test on macOS with Julia 1.14 until the runtime is fixed; everything else keeps running there. The upstream fix is to restore the dead-thread check in
catch_mach_exception_raise_state_identity.