Intermittent SIGSEGV in Maglev concurrent compilation on Linux (PersistentHandles::GetHandle) — regression between v24.14.1 and v24.15.0

[mcollina]

Version

v24.15.0 through v24.18.1 (current LTS). v24.14.1 is not affected.

Platform

Linux 6.8.0-136-generic x86_64 (Ubuntu 24.04.4, glibc 2.39) — also observed on GitHub Actions ubuntu-latest. Not the Windows-only issue from #62991 (that was fixed in v24.16.0; this reproduces on Linux through v24.18.1).

Subsystem

v8 (Maglev)

What steps will reproduce the bug?

The trigger is CPU-hot JS tiering up to Maglev while the machine is CPU-starved, so the repro pins several node processes to two cores. I hit it with an undici test that runs tight request/teardown loops, but the crash is in V8's concurrent compiler thread and has nothing to do with undici's native surface (no addons; the crashing thread is a Maglev compile job):

git clone https://github.com/nodejs/undici.git && cd undici # tested at c76fe46e
npm i
for i in $(seq 1 6); do
 (taskset -c 0,1 node test/http2-request-never-settles.js >/dev/null 2>&1; echo "run $i: exit $?") &
done; wait

Repeat the batch a few times; on v24.18.x roughly 1 in 5–10 processes exits 139 (SIGSEGV) with no output.

How often does it reproduce? Is there a required condition?

With 6 processes pinned to 2 cores (48 runs per version, same machine):

Node	V8	SIGSEGV rate
v24.14.1	13.6.233.17-node.44	0/96
v24.16.0	13.6.233.17-node.49	1/48
v24.18.0	13.6.233.17-node.50	9/48
v24.18.1	13.6.233.17-node.50	5/48
v24.18.1 --no-maglev	13.6.233.17-node.50	0/48

CPU contention is the required condition — on an idle machine with a single process it passes reliably. --no-maglev eliminates the crash entirely.

The regression window is the V8 cherry-picks between 13.6.233.17-node.44 (v24.14.1) and -node.48/49 (v24.15.0/v24.16.0), with the rate increasing at -node.50.

What is the expected behavior? Why is that the expected behavior?

The process should not segfault.

What do you see instead?

The child dies on SIGSEGV with no output at all, which surfaces in node:test/borp-based CI as the file-level ✖ ... 'test failed' with no failing subtest — easy to misread as a flaky test. Real-world sighting on undici's CI (Node 24.18.0, ubuntu-latest): https://github.com/nodejs/undici/actions/runs/30488013544/job/90698464241?pr=5623

Native stack captured with segfault-handler, identical in 6 of 7 crashes (addresses symbolized with addr2line against the release binary):

PID 31631 received SIGSEGV for address: 0x10013a01aa0
v8::internal::PersistentHandles::GetHandle(unsigned long)
v8::internal::compiler::BytecodeArrayRef::SourcePositionTable(v8::internal::compiler::JSHeapBroker*) const
v8::internal::maglev::MaglevGraphBuilder::MaglevGraphBuilder(v8::internal::LocalIsolate*, v8::internal::maglev::MaglevCompilationUnit*, v8::internal::maglev::Graph*, v8::internal::maglev::MaglevCallerDetails*)
v8::internal::maglev::MaglevCompiler::Compile(v8::internal::LocalIsolate*, v8::internal::maglev::MaglevCompilationInfo*)
v8::internal::maglev::MaglevCompilationJob::ExecuteJobImpl(v8::internal::RuntimeCallStats*, v8::internal::LocalIsolate*)
v8::internal::OptimizedCompilationJob::ExecuteJob(v8::internal::RuntimeCallStats*, v8::internal::LocalIsolate*)
v8::internal::maglev::MaglevConcurrentDispatcher::JobTask::Run(v8::JobDelegate*)
v8::platform::DefaultJobWorker::Run()
node::(anonymous namespace)::PlatformWorkerThread(void*)

The faulting addresses look like out-of-cage pointers (0x10013a01aa0, 0x1004128d270), consistent with a bogus persistent-handle index/slot read on the background thread.

One outlier crash (1 of 7) was a null deref on the main thread instead:

PID 32143 received SIGSEGV for address: 0x0
node::CallbackQueue<...>::CallbackImpl<node::crypto::TLSWrap::EncOut()::{lambda(node::Environment*)#2}>::Call(node::Environment*)
node::Environment::RunAndClearNativeImmediates(bool)
node::Environment::CheckImmediate(uv_check_t*)
uv_run

Possibly fallout from the same corruption, but noting it in case it's a separate race.

Additional information

The workload that triggers it is pure JS churn: an HTTP/2 client/server in-process with rapid stream resets, GOAWAYs and session teardown, i.e. lots of short-lived hot functions being tiered up concurrently. Happy to help narrow the V8 cherry-pick range or test candidate fixes.

---

Disclaimer: I created this report with the help of AI.

[mcollina]

@nodejs/v8 I'm not sure if this is something we want to handle.

[mcollina]

cc @nodejs/tsc

[mcollina]

I reproduced this independently on a native, non-virtualized Linux x64 host with the official Node v24.18.0 binary. This was not Docker/Rosetta.

Running test/http2-request-never-settles.js directly passed. In one eight-process concurrent batch, 5/8 processes terminated on SIGSEGV (shell status 139). The same batch with native Node v26.3.1 was 0/8.

I captured a core before using gdb. This crash is a different PersistentHandles manifestation from the common GetHandle() stack above:

#0 v8::internal::PersistentHandles::~PersistentHandles()
#1 v8::internal::maglev::MaglevCompilationInfo::set_persistent_handles(...)
#2 v8::internal::maglev::MaglevCompilationJob::ExecuteJobImpl(...)
#3 v8::internal::OptimizedCompilationJob::ExecuteJob(...)
#4 v8::internal::maglev::MaglevConcurrentDispatcher::JobTask::Run(...)
#5 v8::platform::DefaultJobWorker::Run()
#6 node::(anonymous namespace)::PlatformWorkerThread(void*)
#7 start_thread
#8 clone3

The faulting state was:

rdi = 0x10000000000
rip = PersistentHandles::~PersistentHandles()+16

=> mov (%rdi), %rax

I also made an intermediate reproduction that uses Undici but does not import node:test, runs seed 7 from an async main(), and preserves dynamic certificate generation, aborts, REFUSED_STREAM retry, GOAWAY, action ordering, and cleanup. Under the same eight-process load it terminated on SIGSEGV in 3/8 processes. A core from that version had the same destructor stack, instruction, and rdi value. This establishes that node:test is not required.

Eight-process Node v24.18.0 control batches:

--jitless 0/8
--no-opt 3/8 SIGSEGV
--no-maglev 0/8
--no-concurrent-recompilation 0/8

Replacing REFUSED_STREAM with CANCEL, disabling Undici's REFUSED_STREAM retry, using client-h2.js from before undici commit 39264994, or suppressing scheduled aborts each produced 0/8 in short batches. I regard those as timing/suppression clues, not causal isolation.

The existing raw node:http2 reduction with a custom client passed 0/8 on both Node versions, but it does not preserve Undici's queue/listener/retry lifecycle, so it does not exclude this V8/Node path.

This looks like the same concurrent-Maglev persistent-handle issue, with PersistentHandles::~PersistentHandles() as an additional observed crash site. The stack establishes the immediate failure in the Maglev worker, although it does not by itself prove where the pointer was first corrupted.

[mcollina]

Correction to my earlier conclusion: the Maglev stacks are where corrupted state is detected, not the source of the corruption.

A stronger native repro also crashes Node v24.14.1, so the V8 regression window reported in this issue is invalid. Several plausible V8 persistent-handle fixes were backported and tested independently; none stopped the crash. Valgrind and subsequent reduction instead exposed invalid nghttp2 accesses during reentrant HTTP/2 reset/session teardown.

The relevant root fix is #64166, which prevents Node from calling nghttp2 send/close paths while nghttp2_session_mem_recv() callbacks are active. The narrower REFUSED_STREAM deferral already present in the latest v24 line is not sufficient: it still produced 2 SIGSEGVs in 256 concurrent native runs. A v24-adapted backport of the full fix completed 256/256 concurrent runs with no abnormal exits, all 277 Node HTTP/2 tests, and all 116 Undici HTTP/2 tests.

A direct cherry-pick of #64166 is not sufficient for v24 because that commit assumes later HTTP/2 lifecycle changes. It causes a deterministic missing-onread assertion when a session is destroyed during a receive callback and also breaks reset/trailer ordering. The tested adaptation adds close-pending callback guards and preserves v24's reset and trailer ordering.

--no-maglev remains an effective temporary CI mitigation because it prevents the observed corrupted state from surfacing in Maglev, but it is not the root fix. This should be routed to HTTP/2/nghttp2 rather than V8.

[pacocartones]

Reproduced here too, with a couple of data points that may help scope it:

• Still reproduces on top of current undici main (86b62998, i.e. later than the c76fe46e in the report), using this issue's recipe on WSL2 (Ubuntu 24.04, kernel 6.18): batches of 6 × taskset -c 0,1 node test/http2-request-never-settles.js. v24.18.1: 1/72 and 4/72 SIGSEGV (exit 139) in two independent run sets. The dead process's log matches the CI signature byte for byte: one TAP line (✔ every h2 request settles under connection churn (seed 7)), then nothing.
• v24.19.0 (current LTS) is still affected: 4/72 SIGSEGV — so the V8 backport in 24.19.0 does not (fully) cover this one.
• --no-maglev removes the SIGSEGV (0/48) but the workload is still not clean: 1/48 SIGABRT with glibc corrupted size vs. prev_size — which looks consistent with the TLSWrap outlier noted above; there seems to be residual native instability under CPU starvation beyond the Maglev crash.
• Controls: v24.14.1 (336 runs, including an amplified variant with ~30k requests) and v24.18.1 on Windows (72 runs, same recipe): 0 failures — consistent with the Linux-only, ≥ 24.15.0 framing.

(FWIW: this test going red intermittently is currently painting unrelated undici PRs red — #5637, #5673, #5675 all fail CI with only this file, same signature.)