CommandCodeAI / CommandCodeAI/command-code

JavaScript heap out of memory during startup on macOS (v1.10.0)

未關閉
#624 2 則留言 1 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

主要語言
沒有語言資料
星號
4k
分支
350
PR 合併指標
30 天內沒有已合併 PR

描述

Summary

Running cmd on macOS causes Command Code to consume approximately 4 GB of V8 heap and abort with FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory about 15 seconds after launch.

This was observed on Command Code 1.10.0. Earlier heap-exhaustion reports such as #522 were closed as fixed in v1, with a request to open a new issue if the problem still occurs on v1.4.0 or later. Unlike those long-session reports, this crash occurs during CLI startup, before normal use.

Expected Behavior

cmd should start the interactive Command Code UI without exhausting the Node.js heap.

Actual Behavior

The process reaches roughly 4.05 GB of live heap, fails repeated Mark-Compact collections, and exits with SIGABRT:

<--- Last few GCs --->

[276:0xca8000000]    15228 ms: Mark-Compact 4046.2 (4143.5) -> 4046.2 (4143.8) MB, pooled: 9 MB, 11.58 / 0.00 ms  (average mu = 0.225, current mu = 0.041) allocation failure; scavenge might not succeed
[276:0xca8000000]    15247 ms: Mark-Compact 4047.2 (4144.7) -> 4047.2 (4144.2) MB, pooled: 9 MB, 18.00 / 0.00 ms  (average mu = 0.122, current mu = 0.034) allocation failure; scavenge might not succeed

<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 0x104456434 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/Users/<user>/.nvm/versions/node/v22.22.2/bin/node]
 2: 0x104631558 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/Users/<user>/.nvm/versions/node/v22.22.2/bin/node]
 3: 0x104840518 v8::internal::Heap::stack() [/Users/<user>/.nvm/versions/node/v22.22.2/bin/node]
 4: 0x10483e8b8 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/<user>/.nvm/versions/node/v22.22.2/bin/node]
 5: 0x104832eac v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/<user>/.nvm/versions/node/v22.22.2/bin/node]
 6: 0x1048336e4 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/<user>/.nvm/versions/node/v22.22.2/bin/node]
 7: 0x104807920 v8::internal::FactoryBase<v8::internal::Factory>::NewRawTwoByteString(int, v8::internal::AllocationType) [/Users/<user>/.nvm/versions/node/v22.22.2/bin/node]
 8: 0x10481826c v8::internal::Factory::NewStringFromUtf8(v8::base::Vector<unsigned char const>, unibrow::Utf8Variant, v8::internal::AllocationType) [/Users/<user>/.nvm/versions/node/v22.22.2/bin/node]
 9: 0x10464da4c v8::String::NewFromUtf8(v8::Isolate*, char const*, v8::NewStringType, int) [/Users/<user>/.nvm/versions/node/v22.22.2/bin/node]
10: 0x104576570 node::(anonymous namespace)::MakeString(v8::Isolate*, char const*, unsigned long, node::encoding) [/Users/<user>/.nvm/versions/node/v22.22.2/bin/node]
11: 0x104576474 node::StringDecoder::DecodeData(v8::Isolate*, char const*, unsigned long*) [/Users/<user>/.nvm/versions/node/v22.22.2/bin/node]
12: 0x104576818 node::(anonymous namespace)::DecodeData(v8::FunctionCallbackInfo<v8::Value> const&) [/Users/<user>/.nvm/versions/node/v22.22.2/bin/node]
...
26: 0x10444db4c node::fs::FSReqPromise<node::AliasedBufferBase<double, v8::Float64Array>>::Resolve(v8::Local<v8::Value>) [/Users/<user>/.nvm/versions/node/v22.22.2/bin/node]
27: 0x10445cc94 node::fs::AfterInteger(uv_fs_s*) [/Users/<user>/.nvm/versions/node/v22.22.2/bin/node]
...
36: 0x18499c4e4 start [/usr/lib/dyld]
zsh: abort      cmd

The allocation stack ends in StringDecoder::DecodeData / NewStringFromUtf8, and the asynchronous stack includes node::fs, which may indicate that a large amount of file-backed data is being decoded during startup.

Steps to reproduce the issue
  1. Use Node.js v22.22.2 installed through nvm.
  2. Install/use global command-code@1.10.0.
  3. Run cmd from zsh on macOS.
  4. Wait approximately 15 seconds.
  5. Observe the process abort with a JavaScript heap out-of-memory error.
Command Code Version

1.10.0

Operating System

macOS

Terminal/IDE

Terminal application not yet identified

Shell

zsh

Additional context
  • macOS 26.6 (build 25G72)
  • Apple Silicon (arm64)
  • Node.js v22.22.2
  • npm 10.9.7
  • Command Code is installed globally under nvm.
  • The failure happens around the default V8 heap ceiling; increasing the heap has not been tested and should not be required for normal startup.
  • Related historical report: #522. Its maintainer response says v1 bounded session retention and asks for a new issue for heap OOMs on v1.4.0+.

貢獻指南

這個儲存庫沒有索引到貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

研究方向

首先在 macOS 上使用 Node.js v22.22.2 和 Command Code 1.10.0 重現 cmd,然後檢查啟動時檔案讀取和解碼路徑,這些路徑與堆疊框架 node::fsStringDecoder::DecodeData 有關。完成的標準是:在回報的環境中,互動式 UI 啟動時不會達到 V8 堆積限制。

由索引模型根據 Issue 內容生成。

評估

技術堆疊
javascript, macos, node.js, zsh
領域
cli, devtools, operating-systems
Issue 類型
缺陷
難度
4/5
預估耗時
3-5 天
活躍度
活躍
描述清晰度
基本清楚
新手友好度
48/100

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。