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

re: WITHDRAW "the freeze requires the rasterizer" -- the control was not controlled

Browse Source 
Driving the null backend blind, using the memory screen-id as the guide, to the
SAME screen the rendered run froze on (screen 4):

    guest churn   19 of 8,089,600 bytes in 4 s  (0.000%)
    Main XThread  0 ms CPU / 4 s, state S, wchan futex_do_wait
    log           AllocRange unable ... 134217728 bytes; guest throw

Frozen identically with no rasterizer at all.

The flaw is the comparison, not the data.  The earlier "control" measured the
null-GPU run while it was still in the MENUS and the lavapipe run AT the freeze,
then reported the difference as a backend effect.  The allocations I cited as
proof it had walked through the content load (114 -> 120) were menu-time
allocations.  A control needs both arms verified to be in the same state -- and
the memory screen-id built this same session is exactly what makes that
checkable, which I failed to use on the arm that mattered.

Withdrawn: "the freeze requires the rasterizer", "the fault is in the host
rendering path", and the hardware-Vulkan blocker that followed from it.  The
rendering question is no longer load-bearing.

Survives: the freeze happens on the first content load after the main menu, on
every route and BOTH GPU backends, with Main XThread futex-blocked at zero CPU
rather than spinning; and four runs froze with three different allocation
outcomes, so the 128 MB refusal is correlated but not necessary.

Also survives and is independently verified: the memory screen-id navigation,
now reproduced on a third run.  It is what exposed this error.

Open again: what is Main XThread waiting on?  Identify the futex and its holder,
carefully -- gdb perturbs this measurement.
This commit is contained in:
Sylpheed RE agent
2026-08-26 18:28:47 +00:00
parent c791b3c374
commit 78696338b6
2 changed files with 62 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
docs/re/BACKLOG.md
View File

@@ -6,6 +6,16 @@ unknown, what evidence exists, and what the first step would be. Move an item in
---
## 🔴 ~~BLOCKER — the mission freeze is a software-rendering hang~~ WITHDRAWN (2026-08-26)
> **Withdrawn the same day.** Driving the null backend blind to the *same* screen
> shows it freezes identically — 0.000 % guest churn, `Main XThread` futex-blocked
> at 0 ms CPU, same 128 MB refusal and throw. The earlier control compared a
> null-GPU run still in the menus against a lavapipe run at the freeze, i.e. two
> different game states, and reported the difference as a backend effect. **The
> hardware-Vulkan blocker below does not apply** — rendering is not what is
> blocking this. The text is kept for the reasoning.
## 🔴 BLOCKER — the mission freeze is a software-rendering hang (2026-08-26)
The freeze that blocks every dynamic measurement is in the **host rendering

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

@@ -999,3 +999,55 @@ by guest memory instead of by screen.** The menu state must be readable — the
cleared-stage mask at `0x828F40C0` is already known and pokeable, so the menu
layer keeps its state somewhere findable. A memory-driven `nav_to_flight` would
make `--gpu=null` a complete oracle for every measurement on the backlog.
---
# 🔴🔴 "The freeze requires the rasterizer" is WITHDRAWN — the control was not controlled
**2026-08-26.** The section above concludes `--gpu=null` does not freeze. It is
wrong, and the flaw is in the comparison rather than the data.
Driving the **null** backend blind, with the memory screen-id as the guide, to
the *same* screen the rendered run froze on (`screen = 4`):
guest churn: 19 of 8,089,600 bytes in 4 s (0.000%)
Main XThread: 0 ms CPU / 4 s, state S, wchan futex_do_wait
log: AllocRange unable ... 134217728 bytes
Guest attempted to throw a C++ exception!
**Frozen, identically, with no rasterizer at all** — same futex block, same
128 MB refusal, same throw.
## What went wrong with the comparison
The earlier "control" measured the null-GPU run while it was **still in the
menus**, and the lavapipe run **at the freeze**, then reported the difference as
a backend effect. The two arms were at different points in the game. The
allocations I cited as proof it had "walked through the content load"
(114 → 120) were menu-time allocations; the content load had not happened yet.
**A control needs both arms verified to be at the same state.** The memory
screen-id built this same session is exactly what makes that checkable, and I did
not use it on the arm that mattered.
## What this costs, and what survives
🔴 **Withdrawn**: "the freeze requires the rasterizer"; "the fault is in the host
rendering path"; and the ⚠️ blocker on hardware Vulkan that followed from it —
the rendering question is no longer load-bearing, so it is not what is blocking
this.
✅ **Survives**: the freeze happens on the first content load after the main menu,
on every route, on **both** GPU backends, with `Main XThread` **futex-blocked at
zero CPU** rather than spinning. And the earlier observation stands that four
runs froze with three different allocation outcomes — so the 128 MB refusal is
*correlated* but not necessary.
✅ **Also survives, and is independently verified**: the memory screen-id
navigation ([`menu-state-in-memory.md`](menu-state-in-memory.md)), now reproduced
on a **third** run. It is what exposed this error.
❔ So the open question returns to: **what is `Main XThread` waiting on?** It is
blocked on a host futex with the GPU excluded as the cause. The next lever is the
one not yet tried — identify the futex and its holder — and that needs care,
because gdb perturbs this measurement.