v24.x: "Fatal process out of memory: Zone" crash in V8 turboshaft WASM compilation (WasmLoweringReducer)

Beginne damit, den Absturz mit Node.js v24.x und dem codegraph-Workload zu reproduzieren, und vergleiche dann dieselben Grammatiken unter v22.x, von dem berichtet wird, dass es funktioniert. Verwende den nativen Stack-Trace, um V8 turboshaft's WasmLoweringReducer, SnapshotTable::MergePredecessors und den Zone-Allokationspfad zu untersuchen. Als abgeschlossen gilt die Arbeit, wenn mittelgroße bis große Projekte das Parsen über alle betroffenen Workloads hinweg ohne den fatalen Zone OOM abschließen.

Version

v24.13.1, v24.14.1, v24.15.0 confirmed affected. v22.x LTS works fine.

Platform

macOS arm64 (Darwin 25.3.0, Apple Silicon M1) and Linux x64. Not architecture-specific.

Subsystem

V8 turboshaft WASM compiler — specifically WasmLoweringReducer during tree-sitter grammar compilation.

Severity

100% reproducible. Crashes the entire Node.js process with no JS-level error handling possible.

What steps will reproduce the bug?

1. Install Node.js v24.x
2. Install a package that uses tree-sitter WASM grammars (e.g. npm install -g @colbymchenry/codegraph)
3. Run against a medium-sized project (500+ source files):

cd /path/to/any-project
codegraph init   # or codegraph index if already initialized

The crash occurs consistently at 12-14% parsing progress, when V8's turboshaft pipeline compiles the tree-sitter WASM grammars for Swift/TypeScript/Python/etc.

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

100% of runs. No special conditions — any project with enough diverse file types to trigger multiple tree-sitter WASM grammar compilations will hit it.

The number of files seems to matter: small projects (< ~50 files) may succeed because fewer grammars are loaded. Medium-to-large projects (500+ files, 5+ languages) crash every time at parse phase.

What is the expected behavior? Why is that wrong?

The Node.js process should complete normally. Instead it crashes with a native-level OOM in V8's Zone allocator, which is unrecoverable from JS land.

What do you see instead?

#
# Fatal process out of memory: Zone
#
----- Native stack trace -----

 1: node::NodePlatform::GetStackTracePrinter()::$_0::__invoke()
 2: v8::base::FatalOOM(v8::base::OOMType, char const*)
 3: v8::internal::V8::FatalProcessOutOfMemory(...)
 4: v8::internal::Zone::Expand(unsigned long)
 5: v8::internal::compiler::turboshaft::SnapshotTable::MergePredecessors<...WasmLoweringReducer...>::Bind(...)
 6: v8::internal::compiler::turboshaft::VariableReducer<...WasmLoweringReducer...>::Bind(Block*)
 7: v8::internal::compiler::turboshaft::GraphVisitor<...WasmLoweringReducer...>::VisitBlock<false>(Block const*)
 8: v8::internal::compiler::turboshaft::GraphVisitor<...>::VisitAllBlocks<false>()
 9: v8::internal::compiler::turboshaft::CopyingPhaseImpl<WasmLoweringReducer, MachineOptimizationReducer>::Run(...)
10: v8::internal::compiler::turboshaft::Pipeline::Run<WasmLoweringPhase>()
11: v8::internal::compiler::Pipeline::GenerateWasmCode(...)
12: v8::internal::compiler::turboshaft::ExecuteTurboshaftWasmCompilation(...)
13: v8::internal::wasm::WasmCompilationUnit::ExecuteCompilation(...)
14: v8::internal::wasm::ExecuteCompilationUnits(...)
15: v8::internal::wasm::BackgroundCompileJob::Run(JobDelegate*)
16: v8::platform::DefaultJobWorker::Run()
17: node::PlatformWorkerThread(void*)
18: _pthread_start

Abort trap: 6

Additional information

• Not a JS heap OOM: --max-old-space-size has no effect — this is V8's internal Zone memory, not the managed heap.
• Already tracked downstream: colbymchenry/codegraph#140 (multiple users confirmed, codegraph added a hard-exit guard for Node 25.x but v24.x is also affected and not yet guarded).
• Node 22 LTS unaffected: v22.22.0 works correctly with the same workload and same WASM grammars.
• Likely regression: The Zone allocator in turboshaft's WASM pipeline appears to have a size calculation or growth bug triggered by the size/number of tree-sitter WASM modules.

Stack traces from three separate runs (v24.13.1, v24.15.0, different memory limits) are identical — the crash point is deterministic.