nodejs / nodejs/node

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

Abierto
#63,421 4 comentarios 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

stale v8 engine wasm
Lenguaje dominante
JavaScript
Estrellas
122k
Forks
37.3k
Merge medio
4 d 2 h
PR fusionados (30 d)
283

Descripción

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.

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Línea de trabajo

Empieza reproduciendo el fallo con Node.js v24.x y la carga de trabajo codegraph; después compara las mismas gramáticas con v22.x, que según los informes funciona. Usa el stack trace nativo para investigar V8 turboshaft's WasmLoweringReducer, SnapshotTable::MergePredecessors y la ruta de asignación de Zone. Se considera terminado cuando los proyectos medianos y grandes completan el análisis sintáctico en todas las cargas de trabajo afectadas sin el fatal Zone OOM.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
javascript, node.js, wasm
Área
compilers
Tipo de issue
Error
Dificultad
4/5
Tiempo estimado
3-5 días
Estado de actividad
Activo
Claridad
Bastante claro
Aptitud para principiantes
45/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.