docs/re: the cache-flush throw — a 100-second trigger, and two withdrawals

Chasing the title-screen crash into the emulator's own diagnostics turned it
from a mystery into a controlled experiment, and knocked over two things this
corpus said yesterday.

Withdrawn #1: "the fault address 0x1_0000000C is a pointer with a stale high
word". The crash dump prints r25 = 0x0000000C, clean. Xenia maps the guest's
4 GiB at host 0x1_00000000, so that IS guest address 12. The guest dereferenced
the small integer 12.

Withdrawn #2: "with --mem_watch=false the crash does not happen at all", which
named the crash-oracle handoff's suspect #1 as measured. It was confounded —
every --mem_watch=false run had also had a warm cache. Held cold, the throw
happens with the probe off (2 437 crash dumps). mem_watch is eliminated for this
crash.

What it actually is: the access violation is the guest's own `throw` RETURNING,
because this build logs guest C++ exceptions and continues rather than
unwinding. So the event is the throw, and with --cache_throw_diag=true the guest
names it: std::out_of_range, from the cache-manager flush, with a deque of 38
entries (37 distinct, one duplicated) against a 37-key map, every one of them
absent from the flush's snapshot but present in the live map — the TOCTOU race
the logger's own message describes.

And the new, useful part: the trigger is the on-disc cache. Complete cache, no
throw (2 runs). Directory moved aside or half-rebuilt, throw ~100 s into the boot
(3 runs, including one that threw with NO access violation behind it — which is
why crash dialogs are the wrong thing to count). A suspect in that bisection plan
now costs a `mv` and two minutes instead of a mission.
This commit is contained in:
Sylpheed RE agent
2026-08-18 21:44:22 +00:00
parent d521c802ad
commit 44ff5454f9
5 changed files with 179 additions and 49 deletions

View File

@@ -178,9 +178,14 @@ carries the reproduction and the fix for two of them.
### 2026-08-18 (fourth pass) — the crash is named, and the code avenue is scoped
The crash PC resolves to an MSVC `std::map`/`set` erase that throws
`'invalid map/set<T> iterator'` — a 40-second reproduction of the Ready-Room
crash, in [`title-crash-stl-tree.md`](title-crash-stl-tree.md). That is a
by-product of this item, and it belongs to whoever picks up the crash bisection.
`std::out_of_range` from the game's cache-manager flush, and the trigger is now
controlled: an **incomplete on-disc cache** throws ~100 s into a boot, a complete
one never does. The access violation people have been chasing is only that throw
*returning*, because this build does not unwind guest EH. And the handoff's
suspect #1 is **eliminated** — cold cache with `--mem_watch=false` throws just
the same, which withdraws a claim made here yesterday. See
[`title-crash-stl-tree.md`](title-crash-stl-tree.md). That is a by-product of
this item and belongs to whoever picks up the crash bisection.
For the ordering itself, three more negatives, all recorded in
[`ui-title-paint-order-capture.md`](ui-title-paint-order-capture.md): the two