From 58086feea2033d8aa08cca54c18bc4accf2fa39e Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Mon, 24 Aug 2026 08:35:23 +0000 Subject: [PATCH] docs: a third failure mode - the emulator dies silently, and OOM does not explain it Run 6 ended neither frozen nor in GAME OVER: freeze_watch reported EMULATOR GONE at 810s and the 1.1 MB Canary log simply stops mid-activity, with ZERO occurrences of CRASH, Access Violation, GUEST-THROW, assert, Fatal or abort, and no shutdown line. Memory pressure is recorded as a suspect and explicitly not as a conclusion. The cgroup had reached its 7 GiB ceiling (memory.peak == memory.max) with 4421 allocation stalls at the limit, and page cache - inflated by the disc-wide format sweeps that read every .pak - was 4.68 GB of it. But memory.events:oom_kill is 0, so the cgroup OOM killer did not do this, and nothing identifies what did. Two operational notes fall out: /dev/shm/xenia_memory_* survives a dead run (342 MB resident) and run-canary only clears it at launch, and vm.drop_caches is not writable here, so page cache can only be left to the kernel. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE --- docs/re/mission-freeze-resume-spin.md | 42 +++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/docs/re/mission-freeze-resume-spin.md b/docs/re/mission-freeze-resume-spin.md index 2e218388..bf084dfb 100644 --- a/docs/re/mission-freeze-resume-spin.md +++ b/docs/re/mission-freeze-resume-spin.md @@ -468,3 +468,45 @@ thread clears it 224 times in a normal run. The freeze signal has to be a **different** shape — a thread far above 1 235/s, or a new thread, or a window whose result is *not* SUCCESS. That comparison needs a frozen sample, which run 5 did not provide (GAME OVER at ~22 min). + +## 🔴 A THIRD failure mode: `EMULATOR GONE` — the process dies with no crash marker + +Run 6 (2026-08-24) ended neither in a freeze nor in GAME OVER. `freeze_watch.sh` +reported **`EMULATOR GONE at 810s`**, and the Canary log simply *stops* in the +middle of ordinary activity: + +``` +i> F8000008 [file-pad] #3421 buttons=0000 lt=0 rt=0 lx=-7412 ly=-3620 rx=0 ry=0 +w> F8000254 XThread::Resume: host resume was refused for thread F80001E8 +w> F8000254 XThread::Resume: host resume was refused for thread F80001E8 <- end of file +``` + +**Zero** occurrences of `CRASH`, `Access Violation`, `GUEST-THROW`, `assert`, +`Fatal` or `abort` in the whole 1.1 MB log. No shutdown line either. The process +is just gone. + +### Memory pressure is a suspect, and only a suspect + +The container's cgroup, read immediately after, with **no emulator running**: + +| | | +|---|---| +| `memory.max` | 7 516 192 768 (7 GiB) | +| `memory.peak` | **7 516 196 864 — the ceiling was reached** | +| `memory.events: max` | **4 421** allocation stalls at the limit | +| `memory.events: oom_kill` | **0** | +| `memory.stat: file` (page cache) | **4.68 GB** | +| `memory.stat: shmem` | 358 MB (leftover `/dev/shm/xenia_memory_*`) | +| `memory.stat: anon` | 683 MB | + +So the box really was running at its ceiling, and page cache — inflated by the +disc-wide format sweeps, which read every `.pak` — was most of it. 🔴 **But +`oom_kill` is 0**, so the cgroup OOM killer did not do it, and nothing here shows +*what* did. Recorded as an unexplained third failure mode rather than an OOM +story, because the counter that would have proved OOM says zero. + +**Hygiene that follows either way:** `/dev/shm/xenia_memory_*` survives a dead +run (342 MB resident here) and `run-canary` only clears it at *launch*; and +`vm.drop_caches` is not writable in the container (read-only `/proc/sys`), so +page cache can only be left to the kernel to reclaim. Clearing the stale shm +files between runs is the one lever available.