fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re: the 171 MB of boot allocations are the game's own pools, ~90% empty

Browse Source 
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.
This commit is contained in:
Sylpheed RE agent
2026-08-26 16:59:26 +00:00
parent a9ce94ec83
commit 5ed90577ee
1 changed files with 49 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

49
docs/re/mission-freeze-heap-exhaustion.md
View File

@@ -568,3 +568,52 @@ moving.
58.50 MB at `BC220000`, both before any menu) is avoidable, since that plus a 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 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. 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.