fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

docs: a third failure mode - the emulator dies silently, and OOM does not explain it

Browse Source 
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) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
This commit is contained in:
Sylpheed RE agent
2026-08-24 08:35:23 +00:00
parent 5699b25fc4
commit 58086feea2
1 changed files with 42 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
docs/re/mission-freeze-resume-spin.md
View File

@@ -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.