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

docs/re: the cache-flush crash also fires at SELECT DATA, blocking every mission

Browse Source 
Driving toward a mission for the second capital-ship capture works as far as two
screens nobody had captured — DIFFICULTY, then SELECT DATA — and then the guest
dies at PC 0x82307128, the SAME std::map/set erase as the boot-time throw, with
537 stacked dumps. Both screenshots are committed.

So the ship item's blocker is the crash, not navigation: the game reaches the
save-slot screen and dies enumerating save data. mem_watch stays eliminated —
this run had it off. And the save/cache path is the common factor across both
firings.

Stated as unsettled: whether a warm cache prevents this firing the way it
prevents the boot-time one. The cache WAS warm here, so it looks like no, but
that is a single run and the cold/warm A/B was only ever run against the
boot-time throw.
This commit is contained in:
Sylpheed RE agent
2026-08-19 04:00:53 +00:00
parent b1e788226d
commit fdeb003f1c
1 changed files with 33 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -189,3 +189,36 @@ bisection plan in the handoff is written as "one build + one Ready-Room run" per
suspect. If this title-screen crash is the same defect, each suspect costs **40
seconds** instead, and suspect #1 (`--mem_watch=false`) is already measured here:
it removes the crash.
## It also fires on the way into a mission — which is what blocks the ship capture
**2026-08-19.** Driving the game toward a mission for the second capital-ship
capture (`tutorial_launch.sh`: boot → title → Ⓐ → main menu → two d-pad steps →
Ⓐ) reaches two screens nobody had captured, and then dies:
```
main menu → DIFFICULTY (EASY / NORMAL / HARD / BACK) captures/difficulty-screen.png
→ SELECT DATA (save slots, "Current Storage: Dummy HDD")
→ CRASH: PC 0x82307128, guest thread 9, 537 stacked dumps
captures/select-data-crash.png
```
`0x82307128` is the **same** `std::map`/`set` erase as the boot-time throw. So
the cache-flush defect is not a boot curiosity: it fires again when the game
enumerates save data on the way into every mission, and it paused the emulator
for good — dismissing one dialog only reveals the next of 537.
Three things this pins:
* **The blocker for the second capital-ship capture is this crash, not
navigation.** Navigation works; the game gets as far as the save-slot screen
and dies there. `BACKLOG`'s ship item should be read that way.
* **`mem_watch` stays eliminated**: this run had `--mem_watch=false`.
* **The save/cache path is the common factor** across both firings — the
boot-time one followed `HostPathDevice::ResolvePath(\aab216c3\…)`, and this one
follows the save-slot enumeration.
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.