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

Bắt đầu bằng cách tái hiện sự cố crash với Node.js v24.x và workload codegraph, sau đó so sánh các grammar tương tự trên v22.x, phiên bản được báo cáo là hoạt động. Sử dụng native stack trace để điều tra V8 turboshaft's WasmLoweringReducer, SnapshotTable::MergePredecessors và đường dẫn cấp phát Zone. Được xem là hoàn tất khi các dự án từ trung bình đến lớn hoàn tất việc phân tích cú pháp mà không gặp fatal Zone OOM trên tất cả workload bị ảnh hưởng.

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.