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)

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: #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.

Aucun fichier source, test ou point d’entrée n’est indiqué. Commencez par examiner le rapport de diagnostic de Node.js et reproduire une session Autopilot de longue durée sous Windows avec une pression sur la mémoire de l’hôte ; le travail est considéré comme terminé lorsque la CLI détecte cet échec de commit sous la limite du tas, avertit ou réduit son activité, et préserve la session ou en crée un checkpoint au lieu de l’abandonner.