Repository navigation
Segfault in multithreaded code: NEO SIGSEGV handler race (intel/compute-runtime#1009) #607
Description
We are seeing a sefgault with some code on Aurora. Credit to @j-hayes . Let us know if more info is needed! It should be reproducible on Aurora.
Reproducer
Code
using oneAPI
using Base.Threads
function main()
num_devices = 1
p = 2
W_matricies = Array{oneAPI.oneArray{Float64}}(undef, num_devices)
println("starting"); flush(stdout)
Threads.@threads for device_id in 1:num_devices
oneAPI.device!(device_id)
println("Current iteration: ", device_id)
W_matricies[device_id] = oneAPI.zeros(Float64, p)
println("done $device_id"); flush(stdout)
end
println("done"); flush(stdout)
end
main()
Run
julia --project=/lus/flare/projects/Julia/jacksonjhayes/JuliaChem.jl/aurora_env --threads=4 ThreadedBLASRepo.jl
Activity
michel2323 commentedon Sep 25, 2026
Reproduced on Aurora. This is a bug in Intel's GPU driver (NEO), not in oneAPI.jl.
NEO installs its own SIGSEGV handler, which forwards other faults to Julia's handler. That forwarding isn't thread-safe. Julia deliberately triggers SIGSEGV on every thread during GC, so with more than one thread the driver's handler jumps to garbage and the process crashes.
device!andzerosaren't involved:using oneAPIplus anyThreads.@threadsloop that hits a GC crashes. It works with--threads=1.Reported upstream with a standalone C reproducer and a proposed fix: intel/compute-runtime#1009
[-]Segfault with threaded loop[/-][+]Segfault in multithreaded code: NEO SIGSEGV handler race (intel/compute-runtime#1009)[/+][NEO] Backport fix for SIGSEGV handler chaining race. (#15164)
maleadt commentedon Oct 16, 2026
@michel2323 Fixed for the default stack: NEO_jll 26.35.39758+1 (JuliaPackaging/Yggdrasil#15164) carries your suggested fix, the per-thread
handlerIndex. #706 adds a regression test. Upstream PR: intel/compute-runtime#1025.Aurora uses the system driver (1.6.33578.x, LTS 25.18), so it's still affected, and #706 skips the test when NEO_jll points at a system driver. Could you ask to backport intel/compute-runtime#1025 to the 25.18 LTS branch? It's a one-line change in
shared/source/page_fault_manager/linux/cpu_page_fault_manager_linux.h:On 25.18 the surrounding lines differ slightly, so the PR's diff needs a little fuzz, but the change is the same. The bounds-check fix from master (e613839f3a) would be good to have alongside it, but it only turns the crash into an abort; the
thread_localchange is what fixes it. Once Aurora's driver has the fix, we can drop the skip.