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: # Fatal process out of memory: Zone 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.