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

re: the stage-load freeze is not a regression -- an 08-17 binary reproduces it

Browse Source 
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.
This commit is contained in:
Sylpheed RE agent
2026-08-26 16:19:57 +00:00
parent a65649598e
commit 1a6b9cac34
1 changed files with 28 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
docs/re/mission-freeze-heap-exhaustion.md
View File

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