v1.0.79 fatal "Committing semi space failed" OOM in autopilot with V8 heap only ~0.6/4.3 GB (host-RAM commit failure, not heap limit)

[AndreiTkachyov]

Summary

copilot.exe (v1.0.79) fatally crashed with FATAL ERROR: Committing semi space failed. Allocation failed - JavaScript heap out of memory during a long-running autopilot session. Notably the V8 heap was not near its limit at crash time — used ≈ 607 MB of a 4.30 GB limit — so this is the allocator failing to commit pages from the OS (host physical RAM + pagefile exhausted), not a heap-limit/leak condition. The process aborted rather than degrading gracefully or backing off.

Environment

• CLI version: 1.0.79 (WinGet install)
• Node: v24.18.1, wordSize 64
• OS: Windows_NT 10.0.19045 (x64)
• Mode: autopilot, long-lived session ("Rebuilding reconciled asset bars")
• Host: 32 GB RAM machine that was simultaneously running two heavy external data-build processes (host RAM was near-exhausted at crash time).

Fatal error / GC context (from stderr)

<--- Last few GCs --->
[1824:...] 534881780 ms: Scavenge 635.8 (642.7) -> 634.9 (642.7) MB, pooled: 0 MB ...
[1824:...] 534881907 ms: Mark-Compact (reduce) 638.6 (643.0) -> 574.3 (642.0) MB, pooled: 0 MB ...
FATAL ERROR: Committing semi space failed. Allocation failed - JavaScript heap out of memory

From the Node.js diagnostic report (report.*.json)

• event: Allocation failed - JavaScript heap out of memory
• trigger: OOMError
• javascriptHeap: usedMemory ≈ 607 MB, totalCommittedMemory ≈ 673 MB, memoryLimit ≈ 4.30 GB (heap was only ~14% of limit)
• resourceUsage: rss ≈ 794 MB, maxRss ≈ 1.08 GB, userCpuSeconds ≈ 23,575 (very long-lived session)

Native stack (top frames)

node::GetAnonymousMainPath+292071
node::GetAnonymousMainPath+276925
node::TriggerNodeReport+216
node::OnFatalError+1143
v8::Function::NewInstance+423
uv_udp_get_send_queue_count+54423
...
FATAL ERROR: Committing semi space failed. Allocation failed - JavaScript heap out of memory

Impact

The whole CLI died mid-task in autopilot, losing the interactive session (background/detached child jobs it had launched had to be recovered manually). Because the heap itself was small, a graceful "host low on memory" backoff / warning would very likely have avoided the hard abort.

Suggestions

1. When the OS refuses to commit (semi-space commit failure) while the V8 heap is far below its limit, surface a host-memory-pressure warning and try to persist/checkpoint the session instead of aborting.
2. Consider a lower/adaptive semi-space size under memory pressure, and/or a pre-flight available-memory check before large allocations in long autopilot sessions.
3. Possibly related: Resume of a large session OOMs / grinds one CPU core for ~70 min in 1.0.74 (regression vs 1.0.73; ~3–4× memory) #4251 (large-session OOM regression). This report differs in that the crash is a commit failure with a near-empty heap rather than hitting the heap limit.

I have the full report.20260814.230558.1824.0.001.json and can attach it on request.