CommandCodeAI / CommandCodeAI/command-code
JavaScript heap out of memory during startup on macOS (v1.10.0)
まだ誰も着手していません。
- 主要言語
- 言語のデータがありません
- スター
- 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
- Use Node.js
v22.22.2installed through nvm. - Install/use global
command-code@1.10.0. - Run
cmdfrom zsh on macOS. - Wait approximately 15 seconds.
- 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+.
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず、macOS 上で Node.js v22.22.2 と Command Code 1.10.0 を使って cmd を再現し、その後、スタックフレーム node::fs と StringDecoder::DecodeData が関係している起動時のファイル読み取りおよびデコードのパスを調査します。報告された環境で、V8 ヒープ上限に達することなくインタラクティブ UI が起動すれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- javascript, macos, node.js, zsh
- 領域
- cli, devtools, operating-systems
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 活発
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 48/100