Fatal process out of memory (Zone) during parsing — V8 WASM compilation OOM on Node v24

[a1398394385]

Bug Description

codegraph init -i crashes with Fatal process out of memory: Zone during the parsing phase at ~78%. This is not a system-level OOM — the system has plenty of available memory. The crash is a V8 Zone allocator OOM triggered during WebAssembly compilation.

Environment

• CodeGraph version: 0.7.9
• Node.js version: v24.13.0 (via nvm)
• OS: macOS Darwin 25.5.0 (ARM64, Apple Silicon)
• Hardware: Mac Mini, Apple M-series (10 CPUs), 32GB RAM
• Project size: 2,583 files

Memory at Crash Time

• Total system RAM: 32 GB (34,359,738,368 bytes)
• Available memory (free + inactive + speculative): ~17 GB (1,125,561 pages × 16KB page size)
• This is NOT a system OOM — vast memory headroom at the time of the crash.

Stack Trace

The crash trace goes entirely through V8's TurboShaft WASM compilation pipeline:

Fatal process out of memory: Zone

 1: node::NodePlatform::GetStackTracePrinter()
 2: v8::base::FatalOOM()
 3: v8::internal::V8::FatalProcessOutOfMemory()
 4: v8::internal::Zone::Expand()              ← Zone allocator exhausted
...
10: v8::internal::compiler::turboshaft::Pipeline::Run<WasmLoweringPhase>()
11: v8::internal::compiler::Pipeline::GenerateWasmCode()
12: ExecuteTurboshaftWasmCompilation()
13: wasm::WasmCompilationUnit::ExecuteCompilation()
...

The crash is in WasmLoweringReducer → WasmLoweringPhase → GenerateWasmCode → ExecuteTurboshaftWasmCompilation.

Root Cause Analysis

This crash is consistent with Node.js v24's TurboShaft compiler running out of V8 Zone memory when loading tree-sitter WASM grammars. CodeGraph uses tree-sitter for parsing multiple languages (TypeScript, Python, Go, Rust, Java, etc.), and tree-sitter loads its language parsers as WebAssembly modules. V8's Zone allocator has a limited budget for WASM compilation, and when multiple tree-sitter WASM grammars are loaded simultaneously, the Zone is exhausted.

Key observations:

1. The project has 2,583 files spanning many languages (the config includes 20+ language parsers)
2. No .wasm files exist in the project itself — the WASM compilation is from tree-sitter's language parsers
3. The existing .codegraph/codegraph.db was partially built (70.4MB partial index), suggesting parsing gets partway through before the Zone is exhausted
4. The crash is reproducible — it happens consistently at ~78% parsing

Possible Solutions

1. Reduce Node.js memory pressure for WASM: Allow configuring --max-old-space-size or similar Node.js flags
2. Lazy-load tree-sitter parsers: Only compile WASM grammars when needed, not all at once
3. Limit concurrent WASM compilation: Process files in smaller batches
4. Document Node.js version compatibility: Node v24's TurboShaft compiler may have a tighter Zone budget than v22 or v20

Workaround Attempted

Cleared .codegraph/ and retried — same reproducible crash at ~78%.

[a1398394385]

Update: Also crashes under Node.js v22

Tested with Node.js v22.22.3 as well — same crash (SIGTRAP, V8 Zone OOM), same database size (70.4MB partial build). The crash happens slightly earlier (~45-50% parsing progress under v22 vs ~78% under v24), confirming this is a V8 TurboShaft WASM compilation Zone budget issue intrinsic to Node.js >= 22, not specific to v24.

Additional observations

1. The npm package codegraph on the public registry is version 1.0.0 from a different author (not this project). The actual CLI (codegraph v0.7.9) is only accessible via npx or installing from source. Users may hit confusion trying npm install -g codegraph.

2. Even npx --yes codegraph init -i under Node v22 produces the same partial 70.4MB SQLite database before crashing, suggesting a memory ceiling independent of Node.js version (both v22 and v24 hit a hard V8 Zone limit).

3. The stack trace consistently points to WasmLoweringPhase in V8's TurboShaft pipeline, meaning tree-sitter WASM grammar compilation is the trigger regardless of Node.js major version.

[SuperHappycat]

Can I be assigned to this issue?
I believe the root cause is that when ‎codegraph init -i starts parsing, it detects all languages needed across 2,583 files, then sends every needed WASM grammar to the worker thread at once via the ‎load-grammars message. With all the 15-20 languages, V8’s TurboShaft compiler JIT-compiles all the WASM modules simultaneously, which exhausts the Zone allocator before parsing even finishes.
For now, you could try
NODE_OPTIONS="--wasm-lazy-compilation" npx @colbymchenry/codegraph init -i. I hope that helps!

[colbymchenry]

Fixed in 0.9.3 (releasing now). Your diagnosis was spot on — this is V8's turboshaft optimizing WASM compiler exhausting its per-compilation Zone arena while compiling tree-sitter's grammars on a background thread. It's not a system OOM (the Zone is a V8-internal arena), which is why it aborts with GB to spare.

I reproduced the exact crash on the bundled Node 24.16 runtime indexing a 2,880-file / 18-language repo, then worked through the flags:

• --wasm-lazy-compilation is already V8's default, so it changed nothing.
• --no-wasm-tier-up / --no-wasm-dynamic-tiering did not prevent it.
• --liftoff-only is the one that works — it keeps grammar compilation on the Liftoff baseline so turboshaft never runs. The same repo went from a hard crash at ~85% to a clean 19,200-node index.

CodeGraph now launches with --liftoff-only automatically (the bundled launcher passes it; other launch paths re-exec once with it), so there's nothing to configure.

Once 0.9.3 is live on npm, please update and try again:

• npm i -g @colbymchenry/codegraph@latest, or
• npx @colbymchenry/codegraph@latest init -i

(On the registry point you raised — the real package is the scoped @colbymchenry/codegraph; the unscoped codegraph is unrelated.)

Reopen if you still hit it on 0.9.3. Thanks for the thorough report and diagnosis! 🙏