fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

backlog: frozen capture taken, screen_id correction, instrument-provokes-freeze at n=1

Browse Source
This commit is contained in:
Sylpheed RE agent
2026-08-25 09:03:05 +00:00
parent 6900ebe5ca
commit 479632c13b
1 changed files with 29 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
docs/re/BACKLOG.md
View File

@@ -771,6 +771,35 @@ search cannot find a *schedule*.
clock, or measure guest time under gdb so the wait is set in the right units.** clock, or measure guest time under gdb so the wait is set in the right units.**
Chaining Bash calls **within one turn** works and is no longer the limit — the Chaining Bash calls **within one turn** works and is no longer the limit — the
emulator survives between calls; this run spent ~900 s across three. emulator survives between calls; this run spent ~900 s across three.
* ✅✅ **(2026-08-25) FROZEN CAPTURE TAKEN — and the per-thread diff is the result.**
`freeze_waitobj.sh` split into `boot`/`watch`; `watch` waits for the **event**
(`frozen.py` + `in_flight`) instead of sleeping a guessed interval, and caught
it first try. Hard stop, not a hitch: a frame minutes later is
`max_pixel_delta=0` against the capture. Same run, same mission
(`data/waitobj-s02.txt`): **20 → 24 wait frames**, XEvent **19 → 23**,
XSemaphore **8 → 7**, XTimer 1 → 1. 🔑 **17 of 24 threads sit on the EXACT
object they were already on** — so this is *not* a whole-emulator stall. What
moves: T105/T67/T68 park on `Wait(XEvent)` and T69 on `Wait(XSemaphore)` having
been running; **T74 and T75 move off a semaphore onto an event** (the only
threads that change what *kind* of object they wait for → chase these first);
T50 drops `WaitMultiple(XEvent,XEvent)` → `Wait(XEvent)`.
* ✅ **(2026-08-25) CORRECTION: `screen_id == flight` is NOT a freeze test.**
The previous entry used it to rule out a freeze. `frozen.py` exists precisely
because a frozen mission still classifies as `flight` (its docstring: 724 s of
identical state, 212 % CPU, classifier happy). Re-testing the saved frames says
that run was genuinely healthy — right, but by luck. **And the "~270 s
black-screen" bound those runs were planned around is not a thing**: the freeze
does not black the screen and keeps no clock (onsets 27/45/83/183/255 s).
* 🟡 **(2026-08-25) One data point that OUR INSTRUMENT provokes the freeze.**
Run flew **~670 s clean** with only the pilot; a heavy-CPU inducer
(`heavy_read.py cpu`) started at 08:59:54 and it froze at **09:00:48 — 54 s
later**, inside the 27–255 s band. Consistent with the existing tally but
**n=1, not causal** (confounder: elapsed mission time). ✅ **Refuted en route:
the I/O was never the cost** — a full uncapped walk of every allocated extent is
**371 MB in 0.1 s**, all page cache; the expense is Python-level CPU, ~4.2 s a
pass. **Settle it with:** alternating inducer-on/off windows within a run,
several runs, compared per unit of *mission* time — cheap now `watch` is
event-driven.
* ~~🚧 BLOCKER: t=210/240 unreachable in one turn~~ — **superseded, see above**; * ~~🚧 BLOCKER: t=210/240 unreachable in one turn~~ — **superseded, see above**;
it rested on an untested assumption that a turn is one shell call. 595 s shell cap − ~220 s boot (a ~190 s title movie that cannot be it rested on an untested assumption that a turn is one shell call. 595 s shell cap − ~220 s boot (a ~190 s title movie that cannot be
tapped through) − ~25 s startup = **~350 s observation ≈ 193 game-seconds**. tapped through) − ~25 s startup = **~350 s observation ≈ 193 game-seconds**.