fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: the freeze is independent of the mask poke -- control run settles it

Browse Source 
challenge-mission-gate.md §5.6 attributes the 128 MB heap failure to a careless
cleared-stage mask poke, concludes that poking only real story ids does not blow
the heap, and ends by asking for the control: repeat without the poke.

Ran it.  nav_to_flight.sh gains SYLPH_NO_POKE=1, which skips the write; only
Stage 1 is selectable without it, so the control changes stage too, which makes
the agreement stronger rather than weaker.

    poked    0x0001FFFE   Stage 02   frozen, 128 MB request refused
    control  untouched    Stage 01   frozen, 128 MB request refused

Both logs carry not merely the same error but the same numbers:

    requested 134217728 bytes, parent free 28969/131072 pages

28969 in both, across two stages and two boots.  So the poke does not cause it
and neither does the stage; the guest reproducibly arrives at a 128 MB request
with ~113 MB free.  An identical free-page count across independent runs also
says the allocation pattern is deterministic -- not a race, not host pressure.

The control was verified three ways, because the first attempt was confounded:
two emulators were alive at once (the previous one survived a pkill).  The mask
was read back as 0x0 from the live mapping, the log was confirmed to be this
run's, and the liveness test was repeated after killing the stale process so
exactly one emulator was running -- three frames at rmse 0.00, and an 8 MB slab
of guest RAM with 0 bytes changed over 3 s.
This commit is contained in:
Sylpheed RE agent
2026-08-26 11:26:44 +00:00
parent 78f097ef1f
commit ef8d2ab0d8
3 changed files with 39 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
docs/re/BACKLOG.md
View File

@@ -720,6 +720,7 @@ search cannot find a *schedule*.
6500 candidates → 32 witnesses at 21/s, and the flags have **zero
contradictions** with the loss data (the one loss is unflagged; every flagged
sample has no losses). That is the check the three previous versions failed.
* ✅ **ROOT-CAUSED 2026-08-26 — see [`mission-freeze-heap-exhaustion.md`](mission-freeze-heap-exhaustion.md).** The freeze is a **guest 128 MB physical allocation being refused** (`MmAllocatePhysicalMemoryEx`, `parent free 28969/131072 pages` ≈ 113 MB) after which the guest throws a C++ exception and stops; the emulator keeps spinning at 399 % CPU, which is why it reads as a hang. **Independent of the cleared-stage mask poke and of the stage** — a `SYLPH_NO_POKE=1` control on Stage 01 froze with the *identical* free-page count as the poked Stage 02 run. This also refutes `challenge-mission-gate.md` §5.6's "poking only real story ids does not blow the heap".
* 🔴 **The freeze is now THE blocker.** Onset across runs: **27, 45, 83, 183,
255 s** (median ~83 s) — usable window is 1–4 min and unpredictable. This run
froze at 45 s with 1 loss, useless for arrivals despite a working instrument.

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

@@ -53,14 +53,35 @@ cleared-stage mask blows the heap on a 128 MB request, and concludes:
This run poked **`0x0001FFFE`** — the value called safe — and hit the **same 128 MB
failure**, with `parent free 28969/131072` against that page's `30633/131072`.
🟡 The two are not identical and the refutation is bounded: there, the failure was
on entering `MISSION SELECT`; here `MISSION SELECT` and the stage list worked, and
the failure came later, during the **take-off load**. So the correct reading is
not "the safe value is unsafe" but that **the poke value is not what decides it** —
both values fail the same 128 MB request, at whichever load happens to arrive when
free pages have drained below it. That page's own open question — *"repeat without
the poke to see whether it fails the same way regardless"* — is now the load-bearing
experiment, and it is still unrun.
### ✅ And the control run settles it: the poke is irrelevant
That page ends with the right experiment — *"repeat without the poke to see whether
it fails the same way regardless"* — so I ran it. `nav_to_flight.sh` gained
`SYLPH_NO_POKE=1`, which skips the write; only Stage 1 is selectable without it,
so the control also changes stage, which makes the agreement stronger rather than
weaker.
| run | mask | stage | outcome |
|---|---|---|---|
| poked | `0x0001FFFE` | Stage 02 | frozen; 128 MB request refused |
| **control** | **untouched, reads `0x0`** | **Stage 01** | **frozen; 128 MB request refused** |
Both logs carry the identical line — not merely the same error, the **same
numbers**:
requested 134217728 bytes, parent free 28969/131072 pages
`28969` in both, across two stages and two boots. The control was verified three
ways: the mask read back `0x0` from the live mapping, the log was this run's, and
the liveness test was repeated with the stale process killed so exactly one
emulator was running (three frames, rmse 0.00; an 8 MB slab, 0 bytes changed in
3 s).
🔴 **So the poke does not cause it, and neither does the stage.** The guest
reproducibly arrives at a 128 MB physical request with ~113 MB free and throws.
The identical free-page count across independent runs says the allocation pattern
up to that point is deterministic — this is not a race and not memory pressure
from the host.
## ⚠️ A frozen game passes the screen classifier