From 1a6b9cac34fb8ad94753a466aee1b203d572531e Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 26 Aug 2026 16:19:57 +0000 Subject: [PATCH] re: the stage-load freeze is not a regression -- an 08-17 binary reproduces it This corpus has a 500-second Stage 02 flight from 2026-08-10, and the canary tree gained the file-pad driver, the UI-draw capture, a threading_posix resume fix and log_stuck_waits between then and now, with the running binary rebuilt on 08-24. So a regression was the obvious suspicion. It is wrong. The container already keeps older builds under /sylph-home/re/bin/, plus a host build from 08-17 that predates all of the 08-19 changes, and run-canary honours $XENIA_BIN -- so this cost no rebuild. The 08-17 binary, same route, same point: 1 alloc failure, 1 guest throw. Identical. So bisecting the emulator is not the way in, and the 08-10 run did not differ by binary either. Whatever let it reach flight is in the route or the game state. That sharpens the open question usefully. Both of the two largest live blocks -- 112.88 MB at B50C0000 and 58.50 MB at BC220000 -- are allocated at boot, before any menu, so 171 MB of the 379.5 MB is fixed regardless of route. The remaining ~208 MB is where a route difference could live, and the ledger can measure it: capture live-bytes at the moment TAKE OFF is pressed for two navigation paths and compare. --- docs/re/mission-freeze-heap-exhaustion.md | 28 +++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/docs/re/mission-freeze-heap-exhaustion.md b/docs/re/mission-freeze-heap-exhaustion.md index 6bbbb84..680ff02 100644 --- a/docs/re/mission-freeze-heap-exhaustion.md +++ b/docs/re/mission-freeze-heap-exhaustion.md @@ -424,3 +424,31 @@ That leaves the two paths clearly separated: The flag is cheap and silent, so it has been **left enabled** in the container's `xenia-canary.config.toml`. + +## 🔴 Not a regression — an older binary reproduces it exactly + +The obvious suspicion was that recent canary work broke it: this corpus has a +**500-second** Stage 02 flight from **2026-08-10**, and the tree gained the +file-pad driver, the UI-draw capture, a `threading_posix` resume fix and +`log_stuck_waits` between then and now, with the running binary rebuilt on +**08-24**. + +The container keeps older builds (`/sylph-home/re/bin/*/xenia_canary`, and a +host build from **08-17** predating all of the 08-19 changes), and `run-canary` +takes `$XENIA_BIN` — so this needed no rebuild. Running the **08-17** binary +through the same route to the same point: + + alloc failures: 1 guest throws: 1 + +**Identical.** So the failure is not new, and bisecting the emulator is not the +way in. ⚠️ That also means the 08-10 run, which flew for 500 s, did *not* differ +by binary — whatever let it reach flight is in the **route or the game state**, +not the build. + +❔ That is the open question now, and it is sharper than "why does it freeze": +**what did the working runs hold in memory that these do not?** Both of the two +largest live blocks — 112.88 MB at `B50C0000` and 58.50 MB at `BC220000` — are +allocated at **boot**, before any menu, so 171 MB of the 379.5 MB is fixed +regardless of route. The remaining ~208 MB is where a route difference could +live, and the ledger can measure it: capture live-bytes at the moment TAKE OFF is +pressed, for two different navigation paths, and compare.