From 5ed90577ee8842022ee2ff0e9be26e1df8f68c2c Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 26 Aug 2026 16:59:26 +0000 Subject: [PATCH] re: the 171 MB of boot allocations are the game's own pools, ~90% empty Read from a LIVE guest (main menu, liveness 98.59%) rather than a frozen one, sampling a page per megabyte: B50C0000 112.82 MB 89.7% zeros, header all zero BC220000 58.45 MB 90.8% zeros, header = pointers into itself Neither holds content at the main menu and neither matches a disc file's size. They are pre-reserved pools claimed at boot and mostly untouched. BC220000's first words -- bc220010, bc79c9c0, bcd24c00, bc220040, bd17cda0, bc79ccc0, all inside [BC220000, BFCA0000) -- interleaved with ordinals 6,0,4,5, 0,1,2,3, are an intrusive free-list. That closes a loop from this morning: the 22 "Release failed because address is not a region start" messages were frees of interior pointers into this exact block. The game suballocates from its own pool and hands the sub-pointers to MmFreePhysicalMemory. Independent confirmation that Xenia is right to refuse them. It sharpens the contradiction rather than resolving it. The budget adds up -- ~171 MB of pools, ~379 MB live at the menu, 128 MB wanted for a content load, about 495 MB of a 512 MB console against Xenia's fixed 16 MB GPU reservation, which is the measured ~15 MB shortfall. But the SAME emulator with the SAME reservation ran a mission for 500 s on 08-10, and that run's evidence is entity hull values sampled from guest memory at 2 Hz, not screenshots, so it is not the frozen-frame illusion that fooled this session twice. So the next thing to vary is the boot inputs -- profile, save data, config -- since B50C0000's request is 0x070D28B0, an odd computed size rather than a round reservation, and so plausibly depends on something configurable. --- docs/re/mission-freeze-heap-exhaustion.md | 49 +++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/docs/re/mission-freeze-heap-exhaustion.md b/docs/re/mission-freeze-heap-exhaustion.md index 052158c..eb8d874 100644 --- a/docs/re/mission-freeze-heap-exhaustion.md +++ b/docs/re/mission-freeze-heap-exhaustion.md @@ -568,3 +568,52 @@ moving. 58.50 MB at `BC220000`, both before any menu) is avoidable, since that plus a 128 MB content load is most of the console. That is the last untested lever, and it is a question about what those two blocks are. + +--- + +# ✅ The 171 MB of boot allocations are the game's own pools, ~90 % empty + +Read out of a **live** guest (main menu, liveness 98.59 %) rather than a frozen +one, sampling a page every megabyte across each block: + +| block | requested | zero fraction | first bytes | +|---|---|---|---| +| `B50C0000` | 112.82 MB | **89.7 %** | all zero | +| `BC220000` | 58.45 MB | **90.8 %** | `bc220010 00000000 bc79c9c0 bcd24c00 bc220040 bd17cda0 bc79ccc0 00000006` | + +Neither holds loaded content at the main menu. Neither matches any disc file's +size (nearest are the `Stage_S*.xpr` at 48–67 MB, none equal). They are +**pre-reserved pools**, claimed at boot and mostly untouched. + +## ✅ And `BC220000` is the suballocator behind the "failed releases" + +Its first words are **pointers into itself** — `bc220010`, `bc79c9c0`, +`bcd24c00`, `bc220040`, `bd17cda0`, `bc79ccc0` are all inside +`[BC220000, BFCA0000)` — interleaved with small ordinals `6, 0, 4, 5, 0, 1, 2, 3`. +That is an intrusive free-list or node table. + +This closes a loop from earlier on this page: the 22 +`BaseHeap::Release failed because address is not a region start` messages were +all frees of **interior pointers into this exact block**. Now it is clear why — +the game suballocates from its own pool here, and hands those sub-pointers to +`MmFreePhysicalMemory`. Confirmation that Xenia refusing them is correct, from +the other direction. + +## ❔ Which sharpens the contradiction rather than resolving it + +So the budget is: the game reserves ~171 MB of pools at boot, holds ~379 MB by +the main menu, and wants 128 MB more for a content load — about 495 MB of a +512 MB console, against Xenia's fixed 16 MB GPU-writeback reservation. That +accounts for the ~15 MB shortfall, and the GPU-writeback probe confirmed the +arithmetic by removing the failure when that 16 MB was freed. + +**But the same emulator, with the same 16 MB reservation, ran a mission for +500 seconds on 2026-08-10** — and that run's evidence is entity hull values +sampled from guest memory at 2 Hz, not screenshots, so it cannot be the +frozen-frame illusion that fooled this session twice. Something about that boot +reserved less, and it is not the binary and not the route. + +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.