From 714c74565f760fee9a50f31a43a2ab07805a5a78 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 19 Aug 2026 11:12:46 +0000 Subject: [PATCH] docs+tools: the threading fix measured 5/5 against 1/5, and a driver lock resume_reliability.sh counts, per boot, whether the title's loader thread became the CALLER of a kernel call. Counting boots where the press reached the title: before the fix 1 of 5 ran the loader; after it, 5 of 5. Three of the post-fix boots were driven far enough to classify the screen and all three reached the MAIN MENU, each with the same shape - title at 216-252s, 40 kernel calls by the loader, 6 ResolvePath reads. The failing boots before had zero of both, every time. Caveat kept in the doc: pre-fix runs were interleaved with compiles and a race is load-sensitive, so the counts corroborate the mechanism rather than carry it. Also fixes a self-inflicted confound. Two runs came back 'title_at_s=none' with the emulator log ending in 'Killed', which I first read as the title detector being too strict. It was not: an earlier copy of the script was still running because 'pkill -f resume_reliability.sh' had matched the shell running it rather than the script, and each of that copy's iterations kills the emulator BY NAME - outside run-canary's lockfile. The harness now takes its own lockfile and refuses a second copy, and the note records that pkill -f matches your own shell. --- docs/re/canary-scripted-input-traps.md | 50 +++++++++++++++++++-- docs/re/captures/resume-fix-reliability.csv | 5 +++ tools/re-capture/resume_reliability.sh | 12 +++++ 3 files changed, 63 insertions(+), 4 deletions(-) create mode 100644 docs/re/captures/resume-fix-reliability.csv diff --git a/docs/re/canary-scripted-input-traps.md b/docs/re/canary-scripted-input-traps.md index ed0603fb..7b85f5af 100644 --- a/docs/re/canary-scripted-input-traps.md +++ b/docs/re/canary-scripted-input-traps.md @@ -577,12 +577,31 @@ On the first clean boot afterwards, the same loader thread is the **caller** on boot before the fix had exactly **zero** of both. That is the predicted change, and it is the strongest evidence available short of a reliability run. +### Measured: 5 of 5 after, against 1 of 5 before + +`tools/re-capture/resume_reliability.sh` boots repeatedly and records, per boot, +whether the loader thread was created and whether it ever became the **caller** +of a kernel call. Counting only boots where the press actually reached the title: + +| | boots | loader ran | reached the main menu | +|---|---|---|---| +| **before** the fix | 5 | **1** | 1 | +| **after** | 5 | **5** | 3 (the others were not driven that far) | + +The three post-fix boots that were driven on all show the same shape: title +detected at 216–252 s, loader thread created, **40** kernel calls by it, **6** +`ResolvePath` asset reads, screen classified `menu`. Before the fix the failing +boots had **zero** of both, every time. + +⚠️ One caveat worth keeping: the pre-fix runs were interleaved with compiles and +other load, and a race is load-sensitive. The post-fix runs were not. The +mechanism is read directly from the code, which is what carries the conclusion; +the counts corroborate it. + ### What is honestly not shown -* 🟡 **That boots now reach the menu reliably.** The post-fix boot drifted into - the attract loop because `skip_intro.sh` fired its single press at 145 s, and - the run before it pressed on the **SQUARE ENIX publisher logo** — see below. A - clean before/after reliability count still needs several boots. +* 🟡 A larger sample. Five boots each way is enough to act on, not enough to + quote a rate. * ⚠️ **`host resume was refused` is not by itself a defect.** Resuming a thread that is not suspended legitimately returns false, and the log fires ~7 times in a normal boot. It is a breadcrumb, not an alarm. @@ -601,3 +620,26 @@ and it is the strongest evidence available short of a reliability run. Now `tools/re-capture/is_title.py` **counts** the green glyph over the whole frame — geometry-independent and specific. Measured: **0** pixels on the SQUARE ENIX logo, **1 520** on a real title, threshold 400. + + +## ⚠️ One emulator at a time has to mean one *driver* at a time (2026-08-19) + +The first reliability batch reported `title_at_s=none` on two runs, with the +emulator log ending in `Killed`. That was read at first as the title detector +having been tightened too far. **It was not.** + +An earlier copy of `resume_reliability.sh` was still running: the `pkill -f +resume_reliability.sh` meant to stop it had matched the *shell running the +command* instead (exit 144) and killed that, leaving the script alive. Each of +its iterations begins by killing the emulator **by name** — which is outside +`run-canary`'s lockfile — so it kept shooting the newer batch's boots. + +Two lessons, both cheap: + +* `pkill -f