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:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user