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

docs/re: the mission path measured end to end — the cache crash is the blocker

Browse Source 
Driving menu -> NEW GAME -> DIFFICULTY -> SELECT DATA -> slot 01 with plain flags
gets further than any run so far: SELECT DATA is reached with ZERO crashes (the
screen is alive — a log_ui_draws probe there records 140 draws over 8 frames),
and then choosing a slot lets the game proceed into a cinematic or load, where it
crashes at 0x82307128 — the same cache-flush std::map erase.

So the crash is intermittent in WHERE it fires, not whether: boot, SELECT DATA,
and now after slot selection. There is no safe path through the menus to be found
by choosing different options.

And it is the blocker for every mission-side experiment — the second capital-ship
capture included. Navigation is not the obstacle any more; it is scripted and
works.

Not settled and said so: how to get past it. --mem_watch=false does not (twice).
--eh_dispatch is still untested because no run with it on has reached a throw.
The black-screen hang is a separate intermittent failure with no diagnosis. A fix
is emulator guest-race work, not RE.
This commit is contained in:
Sylpheed RE agent
2026-08-19 05:08:46 +00:00
parent d0e3dc6f33
commit fa48e39d90
3 changed files with 96 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

BIN
docs/re/captures/select-data-reached-no-crash.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 680 KiB

34
docs/re/title-crash-stl-tree.md
View File

@@ -222,3 +222,37 @@ Not settled: whether a warm cache prevents *this* firing the way it prevents the
boot-time one. The cache was warm here (the 6-file `aab216c3` restored earlier),
so the answer looks like **no** — but that is one run, and the cold/warm A/B was
only ever run against the boot-time throw.
## Standing blocker: the mission path, measured end to end (2026-08-19)
Driving `menu → NEW GAME → DIFFICULTY → SELECT DATA → pick slot 01` with plain
flags (`--mem_watch=false`, no EH knobs) gets **further than any run so far** and
still ends the same way:
| step | outcome |
|---|---|
| main menu → NEW GAME | **DIFFICULTY** |
| DIFFICULTY → Ⓐ | **SELECT DATA**, and this time with **0 crashes** ([capture](captures/select-data-reached-no-crash.png)) — the screen is alive, a `log_ui_draws` probe there records **140 draws over 8 frames** |
| slot 01 → Ⓐ | the game proceeds — several changing frames, a cinematic or load — and then **crashes at `0x82307128`**, the same cache-flush `std::map` erase |
Two things this settles, and one it does not.
**Settled: the crash is intermittent in *where* it fires, not whether.** It has
now been seen at boot, at `SELECT DATA`, and after the save slot is chosen. The
same run reached `SELECT DATA` cleanly and died one screen later. So there is no
"safe path" through the menus to be found by picking different options — the
flush throws whenever it next runs.
**Settled: this is the blocker for every mission-side experiment.** The second
capital-ship capture, in-flight probes, mission-outcome work: all of them are
behind this, and navigation is no longer the obstacle — that part is scripted and
works (`tools/re-capture/newgame_path.sh`, `blackscreen_probe.sh`).
**Not settled: how to get past it.** `--mem_watch=false` does not (measured
twice). `--eh_dispatch` remains untested because no run with it on has reached a
throw. And the black-screen hang is a *separate* intermittent failure that takes
some runs out earlier — it is not the crash, and it has no diagnosis yet.
The cheap trigger from the top of this note (an incomplete on-disc cache) still
stands as the fastest way to reproduce the throw for bisection; what is missing
is a fix, and that is guest-race work in the emulator, not RE.