[Bug] Desktop host aborts with "JavaScript heap out of memory" (~2.9 GB) and the 4 GB heap cap cannot be raised from outside

[zhongyaoli]

Environment

• macOS (Apple Silicon), DSH Desktop 0.2.1-rc.5
• Host is a child process spawned with ELECTRON_RUN_AS_NODE=1
• require('v8').getHeapStatistics().heap_size_limit = 4192 MB

Symptom

Three host crashes in 24 h, all identical:
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
GC: Mark-Compact (reduce) 2859.4 (2942.8) -> 2859.1 (2878.3) MB, last resort; GC in old space requested
Crash lands inside node::fs::AfterStat (i.e. any callback can be the drop point — no single culprit).
After the abort the app auto-restarts and re-opens the same large sessions, so it can crash again within minutes.

Why we cannot work around it

Tried all three ways to raise the limit; none works:

1. NODE_OPTIONS=--max-old-space-size=8192 →
   [ERROR:electron/shell/app/node_main.cc:154] Node.js environment variables are disabled because this process is invoked by other apps. — still 4192 MB.
2. Passing --max-old-space-size directly to the binary → still 4192 MB.
3. --js-flags=--max-old-space-size=8192 → "bad option".
   So only the spawn site inside the app could set it.

Ask

1. Please make the host JS heap limit configurable (pass --max-old-space-size in the spawn args, or expose a setting/env honoured by the host child).
2. Before hitting the cap, degrade gracefully: warn at a threshold, then unload/compact the largest sessions instead of aborting the whole host (an abrupt abort loses in-flight turns and leaves other services in a broken state).
3. On auto-restart, please cap how many large sessions are restored at once (we have several sessions with 200k–2M tokens / 30–45 MB logs; restoring them simultaneously reproduces the OOM in ~4 minutes).

Evidence

Happy to attach the full crash logs if useful; the excerpt above is verbatim from
~/Library/Logs/DeepSeek Harness/crash-*.log.

中文摘要

本机 24GB 内存，24 小时内宿主三次因 JS 堆上限（4192MB）耗尽而 abort，崩在普通 fs 回调里；
外部三种方式（NODE_OPTIONS / 直接传参 / --js-flags）都无法提高上限，只有应用内部 spawn 处能改。
诉求：①上限可配置；②到顶前优雅降级而不是整进程 abort；③自动重启时限制同时恢复的大会话数量。

[Tari-sk]

Summary

The DSH host process (dsh web / app-boot) leaks V8 heap memory. RSS grows steadily at roughly 300–450 MB/h and, after about 10 hours of uptime, the V8 old-space heap reaches its limit and the process crashes with:

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

Under systemd Restart=always the process restarts and the cycle repeats. We observed 5 such heap-OOM crashes across 3 independently-configured lanes within a couple of days.

This is a leak, not a transient spike: the last GC before a crash reclaims ~0 MB, i.e. the heap is full of live, reachable objects that GC cannot collect.

Environment

• DSH version: 0.2.1-rc.2 (@deepseek-ai/dsh, installed 2026-10-17)
• Host: Ubuntu, Linux 6.8.0, 4 cores / 15 GB RAM
• Run as 3 separate headless instances (3 systemd user services), each with its own DSH_HOME, port and MCP server. One lane is driven through the MCP bridge, all are also reachable via the web UI.

Observed behavior

• RSS of each host process grows nearly linearly with uptime regardless of workload.
• Two lanes grew at ~430 MB/h while agentsLive stayed at 0 for the entire observation window (see timeline below).
• After ~10 h the process hits the V8 heap limit (~4 GB) and OOM-crashes.
• Restarting an idle lane returns RSS to ~60–130 MB immediately, and it grows again.

Evidence

Last GC before a crash (lane 1, dsh.log):

<--- Last few GCs --->
[3035411:0x718a000] 36112432 ms: Mark-Compact 4060.3 (4143.5) -> 4059.5 (4143.0) MB, pooled: 1 MB
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

• 36112432 ms ≈ 10.03 h uptime at crash.
• Heap 4060 / 4143 MB (V8 limit ≈ 4 GB).
• Mark-Compact only reclaims 4060.3 → 4059.5 MB (~0.8 MB) → objects are live, not garbage.

Heap-OOM crash count per lane (grep -c "heap out of memory" dsh.log):

• lane 1: 3
• lane 2: 1
• lane 4: 1

Growth timeline (15-min polling, VmRSS), all after a fresh restart:

lane	after restart	at ~4.8–5.0 h	agentsLive throughout
lane 2	66 MB	2297 MB	0
lane 4	59 MB	2236 MB	0
lane 1	(baseline)	2200 MB → 4162 MB over ~5 h	2 (same 2, pinned for 5+ h)

Ruled out:

• Not disk-backed state: state.db is small (71 MB / 29 MB / 27 MB) and not the growth source.
• Not a per-session count issue: crash occurs even on the idle lane with 0 live sessions.

Secondary observation (possibly related)

One lane held the same 2 agents pinned for 5+ continuous hours (never released after their tasks finished) while its memory climbed ~1.9 GB. Agent/session teardown may not be releasing state. This is a separate defect but likely in the same area as the heap accumulation.

Impact

On a 15 GB box, 3 lanes consumed ~9.3 GB RSS over ~10 h and pushed the host into swap; each lane OOM-crashes roughly once per day if left running. This makes long-lived headless DSH deployments unreliable.

Workaround

We restart each idle lane when RSS crosses a threshold (e.g. >2.2 GB and agentsLive == 0), on a 15-min timer. That keeps memory flat but is not a fix — it just resets the leak.

Version notes

• Checked 0.2.1-rc.5 (current latest): no memory-leak / heap-OOM fix (changes are UI, model-listing, stdout diagnostics).
• 0.2.2-alpha.2 does contain a few disposal/cap commits (e.g. fix(trajectory): cap live tool results per session, fix(forge-panel): release cached state with its Session scope) that may be relevant, but it is a large alpha jump so we have not adopted it yet.

Happy to provide full logs, a minimal repro, or run a specific branch to help bisect — let me know what would be most useful.