From d8f0a5e7981021ef8e38abc14f4f2e0b17694ea3 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 26 Aug 2026 17:15:03 +0000 Subject: [PATCH] re: the allocation failure is definitively not the freeze -- four runs, three outcomes Four runs now freeze at the first content load after the main menu with three different allocation outcomes: stock (fails at 128 MB and throws), GPU-writeback patched (no failure, stops at 32 MB), heavy XMA logging (no failure, stops at 16 MB), and no-savegame (no failure, no throw). The memory account on this page is accurate but describes a symptom; everything treating the 128 MB refusal as the freeze is superseded. The savegame is not the variable. --content_root pointed at a profile-only tree (the real content untouched) boots to the identical pools -- BC220000 Size 03A80000 and B50C0000 Size 070E0000, same addresses and sizes, same 43 allocations by the menu -- then freezes at the same press with zero failures. Not slow shader compilation either. Every earlier run called it frozen within ~30 s; this one was left six minutes at 0.00% liveness with CPU still 399-479%. Correction made mid-measurement: the allocation counter creeping 119->124 looked like "guest running, display stuck". It is not. A broad sample -- 400 extents, 8.2 MB -- changed 18 bytes in 3 seconds. The guest is spinning, with one thread allocating about once a minute. The earlier "8 MB slab unchanged" reading was weak for the same reason in reverse: one arbitrary region proves little. Sample broadly before calling a guest alive or dead, exactly as the screen needed two frames rather than one. Now excluded: the heap failure, the leak, rounding, MmQueryStatistics, a heap-size knob, the exception cvar, a kernel-object wait, a build regression, the route, the savegame, and shader compilation. --- docs/re/mission-freeze-heap-exhaustion.md | 56 +++++++++++++++++++++++ 1 file changed, 56 insertions(+) diff --git a/docs/re/mission-freeze-heap-exhaustion.md b/docs/re/mission-freeze-heap-exhaustion.md index eb8d8746..2695c246 100644 --- a/docs/re/mission-freeze-heap-exhaustion.md +++ b/docs/re/mission-freeze-heap-exhaustion.md @@ -617,3 +617,59 @@ The next thing to vary is therefore the **boot inputs**: profile, save data and `xenia-canary.config.toml`. `B50C0000`'s request is `0x070D28B0` — an odd, computed size, not a round reservation — so it plausibly depends on something configurable. + +--- + +# 🔴 The allocation failure is definitively **not** the cause + +Four runs now freeze at the same point — the first content load after the main +menu — with three different allocation outcomes: + +| run | change | allocation outcome | froze? | +|---|---|---|---| +| stock | — | **fails** at 128 MB, guest throws | yes | +| GPU writeback 16 MB → 1 MB | emulator patch | none, stops at 32 MB | yes | +| heavy XMA debug logging | logging | none, stops at 16 MB | yes | +| **no game save** (`--content_root` to a profile-only tree) | boot input | **none, no throw** | yes | + +The memory account on this page is accurate and still worth having, but it +describes a **symptom**. Everything above that treats the 128 MB refusal as the +freeze is superseded by this table. + +## 🔴 The savegame is not the variable either + +`--content_root=/tmp/content-nosave-a`, containing a copy of the profile and no +game save (the real content tree untouched), boots to the **identical** pools: +`BC220000 Size: 03A80000` and `B50C0000 Size: 070E0000`, same addresses, same +sizes, same 43 allocations by the menu. Then freezes at the same press, with +**zero** allocation failures and **zero** throws. + +## ✅ It is not slow shader compilation either + +Every earlier run called it frozen within ~30 s. Under lavapipe a content load +could plausibly be compiling shaders, so this one was left for six minutes: + + t+1min liveness 0.00% allocs 121 cpu 479% + t+2min liveness 0.00% allocs 122 cpu 461% + ... + t+6min liveness 0.00% allocs 124 cpu 399% + +No recovery, and no sign of one. + +## ⚠️ And a correction I made mid-measurement + +The allocation counter creeping (119 → 124) briefly looked like "the guest is +running, only the display is stuck". **It is not.** A *broad* guest-memory +sample — 400 extents, 8.2 MB — changed **18 bytes in 3 seconds**. The guest is +stuck; one thread still allocates roughly once a minute at 400 % CPU, which is a +spin, not progress. + +The earlier "8 MB slab at `0x40000000` unchanged" reading was also weak evidence +for the opposite reason — one arbitrary region proves little either way. **Sample +broadly before calling a guest alive or dead**, the same way the screen needed +two frames rather than one. + +❔ So the oracle is still broken and the cause is unidentified. What is now +excluded: the heap failure, the leak, allocation rounding, `MmQueryStatistics`, +a heap-size knob, the exception cvar, a kernel-object wait, a build regression, +the navigation route, the savegame, and slow shader compilation.