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

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.

Start by reproducing the crash with Node.js v24.x and the codegraph workload, then compare the same grammars under v22.x, which is reported to work. Use the native stack trace to investigate V8 turboshaft's WasmLoweringReducer, SnapshotTable::MergePredecessors, and Zone allocation path. Done means medium-to-large projects complete parsing without the fatal Zone OOM across the affected workloads.