v24.x: "Fatal process out of memory: Zone" crash in V8 turboshaft WASM compilation (WasmLoweringReducer)
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 新手友好度
- 45/100
- Issue 類型
- 缺陷
- 描述清晰度
- 基本清楚
- 活躍度
- 活躍
- 技術堆疊
- javascript, node.js, wasm
- 領域
- compilers
研究方向
先使用 Node.js v24.x 和 codegraph 工作負載重現崩潰，然後在據報能正常運作的 v22.x 下比較相同的文法。使用原生堆疊追蹤調查 V8 turboshaft's WasmLoweringReducer、SnapshotTable::MergePredecessors 以及 Zone 配置路徑。完成的標準是：中型到大型專案在所有受影響的工作負載下都能完成剖析，而不會發生 fatal Zone OOM。
由索引模型根據 Issue 內容生成。
描述
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?
- Install Node.js v24.x
- Install a package that uses tree-sitter WASM grammars (e.g.
npm install -g @colbymchenry/codegraph) - 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-sizehas 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.
- 主要語言
- JavaScript
- 星號
- 122k
- 分支
- 37.4k
- 平均合併
- 4 天 11 小時
- 30 天內合併 PR
- 294
環境準備
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
nodejs/node 的其他 Issue
-
test
難度 2/5 1-3 小時 新手友好度 68/100
維護者通常 1 天內回覆
-
doc
難度 1/5 1 小時以內 新手友好度 90/100
維護者通常 1 天內回覆
-
doc
難度 2/5 1-3 小時 新手友好度 65/100
維護者通常 1 天內回覆
-
build
難度 1/5 1 小時以內 新手友好度 88/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 84/100
nodejs/node#65994 · 2 則留言 · 2 個 reaction ·
維護者通常 1 天內回覆
相似的 Issue
-
bug good first issue
難度 2/5 1-3 小時 新手友好度 86/100
amponce/archive-movie-browser#354 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 74/100
saayam-for-all/webapp#1870 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 76/100
Imageomics/OpenCite#66 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 64/100
chr15m/twiiit.com#20 ·
-
documentation
難度 2/5 1-3 小時 新手友好度 88/100
antropos17/Aegis#629 ·
維護者通常 4 天內回覆