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

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.

まず、undici のワークロード test/http2-request-never-settles.js を使って pinned-core の再現を実行し、v24.14.1 から v24.18.1 までと --no-maglev の結果を比較します。PersistentHandles::GetHandle 周辺の V8 Maglev の並行コンパイルパスと報告されたスタックを読み、その後、関連する V8 の cherry-pick を絞り込みます。Maglev を有効にしたまま、Linux 上でストレス再現が segfault しなくなれば完了です。