[Bug] 长时间运行后 host 进程 V8 堆耗尽崩溃(JavaScript heap out of memory),且崩溃后应用无法自愈
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 22
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
提交前确认 · Pre-submission checklist
- 我已搜索过现有 issue,确认这不是重复 / I searched existing issues and confirmed this isn't a duplicate.
- 我已阅读 CONTRIBUTING.md / I've read CONTRIBUTING.md.
问题类别 · Category
稳定性 / 崩溃 · Stability / Crash
涉及的 Agent 框架 · Agent framework
ZCode Agent(自研)
严重程度 · Severity
影响体验 · Major(功能可用但体验受损 / works but degraded)
复现频率 · Reproducibility
偶现 · Sometimes(长时间连续使用后必现——两次事故分别发生在 host 连续运行 6 小时和 11.3 小时后)
问题描述 · Description
host 子进程(zcode-host-local)长时间运行后,V8 JavaScript 堆持续增长(实测约 200~330 MB/小时),最终顶到默认 ~2GB 堆上限触发 V8 OOM 崩溃(exit code 133)。崩溃后主进程不会重启 host,整个应用进入"僵尸"状态:窗口还在、远程控制端显示"桌面端挂了"(desktop-disconnected),只能手动重启应用恢复。
两个关键点:
- 不是系统内存不足——两次事故时系统均剩余数 GB 可用内存,内核无任何 OOM-kill 记录;这是 V8 进程内部堆上限的问题
- host 启动参数没有任何
--max-old-space-size设置,走的是 Node 默认 ~2GB 上限
复现步骤 · Steps to reproduce
- 持续使用 ZCode 桌面端进行较长时间的 Agent 会话(本例为远程控制场景,多会话、长上下文积累)
- 保持 host 进程连续运行 6~11 小时,期间堆稳定增长
- 堆达到 ~2045MB 上限 → host 崩溃,应用失去全部功能
期望表现 · Expected behavior
- host 能及时释放不再使用的堆内存,或按机器内存设置更合理的堆上限
- host 崩溃后主进程应能自动重启 host 自愈(目前完全不会)
实际表现 · Actual behavior
host 以 exit code 133 崩溃(V8 OOM),主进程仅记录 spawnHostProcess exited,之后应用整体不可用,远程端显示"桌面端挂了",必须手动重启。
ZCode 版本 · ZCode version
v3.9.1(Electron 41.0.3)
设备 / 系统 · Device / OS
联想小新 Pro 16 / Ubuntu 26.04 LTS / GNOME Wayland / 12GB 内存(系统内存充足)
截图 / 录屏 / 日志 · Screenshots / Recordings / Logs
事故 1(2026-08-25 10:49:33,host 已连续运行 11.3 小时):
[1485071:0x2d24001c4000] 40777693 ms: Incremental Mark-Compact (reduce) 2045.2 (2049.4) -> 2045.2 (2048.9) MB, pooled: 0.0 MB ... allocation failure
[1485071:0825/104933.308801:ERROR:electron/shell/common/node_bindings.cc:185] OOM error in V8: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
[spawnHostProcess] host process (local-1) exited with code 133
事故 2(2026-08-27 00:32:58,host 已连续运行 6.0 小时):
[1816477:0x207c001c4000] 21406088 ms: Mark-Compact 2045.9 (2050.4) -> 2044.1 (2050.4) MB, pooled: 0.0 MB ... allocation failure; scavenge might not succeed
[1816477:0827/003258.690928:ERROR:electron/shell/common/node_bindings.cc:185] OOM error in V8: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
[spawnHostProcess] host process (local-1) exited with code 133
[stability] perf_crash reported { crash_id: 'da4a31ef-57cf-42c1-ba60-0b0ae228a1ae', crash_kind: 'native', crash_scope: 'host', crash_cause: 'process_crashed' }
(另有事故 1 的 crashpad pending 记录 id:f5df183b-997d-4bb3-b89e-668494dfaff1)
临时缓解:给应用注入 NODE_OPTIONS=--max-old-space-size=4096 可把到顶时间翻倍,但治标不治本——若连续运行超过一天,4GB 也会顶爆。长会话上下文疑似在 host 堆中持续累积未释放(泄漏),建议排查 host 的内存增长来源。
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the zcode-host-local process and the spawnHostProcess exit handling mentioned in the logs. Reproduce a long-running session while profiling heap growth, then trace which host data remains retained and how the main process handles exit code 133. Done means the retention is addressed and a crashed host is restarted so the application recovers without a manual restart.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- electron, javascript, node.js
- Domain
- desktop, performance
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100