René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Intermittent SIGSEGV in Maglev concurrent compilation on Linux (PersistentHandles::GetHandle) — regression between v24.14.1 and v24.15.0","articleBody":"### Version\n\nv24.15.0 through v24.18.1 (current LTS). v24.14.1 is not affected.\n\n### Platform\n\nLinux 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).\n\n### Subsystem\n\nv8 (Maglev)\n\n### What steps will reproduce the bug?\n\nThe 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):\n\n```bash\ngit clone https://github.com/nodejs/undici.git && cd undici   # tested at c76fe46e\nnpm i\nfor i in $(seq 1 6); do\n  (taskset -c 0,1 node test/http2-request-never-settles.js >/dev/null 2>&1; echo \"run $i: exit $?\") &\ndone; wait\n```\n\nRepeat the batch a few times; on v24.18.x roughly 1 in 5–10 processes exits 139 (SIGSEGV) with no output.\n\n### How often does it reproduce? Is there a required condition?\n\nWith 6 processes pinned to 2 cores (48 runs per version, same machine):\n\n| Node | V8 | SIGSEGV rate |\n|---|---|---|\n| v24.14.1 | 13.6.233.17-node.44 | 0/96 |\n| v24.16.0 | 13.6.233.17-node.49 | 1/48 |\n| v24.18.0 | 13.6.233.17-node.50 | 9/48 |\n| v24.18.1 | 13.6.233.17-node.50 | 5/48 |\n| v24.18.1 `--no-maglev` | 13.6.233.17-node.50 | 0/48 |\n\nCPU contention is the required condition — on an idle machine with a single process it passes reliably. `--no-maglev` eliminates the crash entirely.\n\nThe 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`.\n\n### What is the expected behavior? Why is that the expected behavior?\n\nThe process should not segfault.\n\n### What do you see instead?\n\nThe 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\n\nNative stack captured with segfault-handler, identical in 6 of 7 crashes (addresses symbolized with addr2line against the release binary):\n\n```\nPID 31631 received SIGSEGV for address: 0x10013a01aa0\nv8::internal::PersistentHandles::GetHandle(unsigned long)\nv8::internal::compiler::BytecodeArrayRef::SourcePositionTable(v8::internal::compiler::JSHeapBroker*) const\nv8::internal::maglev::MaglevGraphBuilder::MaglevGraphBuilder(v8::internal::LocalIsolate*, v8::internal::maglev::MaglevCompilationUnit*, v8::internal::maglev::Graph*, v8::internal::maglev::MaglevCallerDetails*)\nv8::internal::maglev::MaglevCompiler::Compile(v8::internal::LocalIsolate*, v8::internal::maglev::MaglevCompilationInfo*)\nv8::internal::maglev::MaglevCompilationJob::ExecuteJobImpl(v8::internal::RuntimeCallStats*, v8::internal::LocalIsolate*)\nv8::internal::OptimizedCompilationJob::ExecuteJob(v8::internal::RuntimeCallStats*, v8::internal::LocalIsolate*)\nv8::internal::maglev::MaglevConcurrentDispatcher::JobTask::Run(v8::JobDelegate*)\nv8::platform::DefaultJobWorker::Run()\nnode::(anonymous namespace)::PlatformWorkerThread(void*)\n```\n\nThe faulting addresses look like out-of-cage pointers (`0x10013a01aa0`, `0x1004128d270`), consistent with a bogus persistent-handle index/slot read on the background thread.\n\nOne outlier crash (1 of 7) was a null deref on the main thread instead:\n\n```\nPID 32143 received SIGSEGV for address: 0x0\nnode::CallbackQueue\u003c...>::CallbackImpl\u003cnode::crypto::TLSWrap::EncOut()::{lambda(node::Environment*)#2}>::Call(node::Environment*)\nnode::Environment::RunAndClearNativeImmediates(bool)\nnode::Environment::CheckImmediate(uv_check_t*)\nuv_run\n```\n\nPossibly fallout from the same corruption, but noting it in case it's a separate race.\n\n### Additional information\n\nThe 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.\n\n---\n\nDisclaimer: I created this report with the help of AI.\n","author":{"url":"https://github.com/mcollina","@type":"Person","name":"mcollina"},"datePublished":"2026-07-30T09:51:10Z","url":"https://github.com/nodejs/node/issues/64841"}