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

docs: the stuck-wait probe and its healthy-run baseline

Browse Source 
The instrument is built (canary auto/re-wait-timeout-probe 83ad0eb3f, binary
archived at /sylph-home/re/bin/waitprobe): consecutive timeouts on the same
object, per thread, logged at 100 and then every 500 - self-selecting where the
global kHighFrequency flag was unusable.

The control is measured: a 25-minute Stage 02 run that never froze produced 27
lines, ALL one thread polling one Event at guest VA BE56BB5C with a ~30 ms
timeout, whose streak reached 8000 while the game ran perfectly. So the probe is
quiet, not silent - the first draft of the cvar help said silent and that is
corrected here - and the freeze signal will be a NEW (thread, object) pair rather
than the presence of output.

Not settled: the freeze did not reproduce this run, so there is no frozen sample
to compare against yet.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
This commit is contained in:
Sylpheed RE agent
2026-08-24 02:30:29 +00:00
parent a29cff9e2e
commit 080ac26197
1 changed files with 33 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
docs/re/mission-freeze-resume-spin.md
View File

@@ -336,3 +336,36 @@ because the boot was not going to finish.
the Release binary has **no DWARF** (`No debugging symbols found` — symtab
only), so `info args` is unavailable and the `PPCContext*` would have to be
dug out of a stack frame by hand. Fragile, but free.
## ✅ 2026-08-24 (later) — the instrument exists: `--log_stuck_waits`
Canary branch **`auto/re-wait-timeout-probe`** (`83ad0eb3f`, off the upstream
baseline) adds a counter in `xeKeWaitForSingleObject`: consecutive `X_STATUS_TIMEOUT`
results on the **same object**, per thread, logged at 100 and then every 500.
It is self-selecting — a wait that is being satisfied never builds a streak — so
it can be left on where the global high-frequency flag cannot. Binary archived at
`/sylph-home/re/bin/waitprobe/xenia_canary`; drive it with
`EXTRA_FLAGS=--log_stuck_waits=true`.
**Healthy-run baseline, which is what a frozen run has to be compared against.**
Over a 25-minute Stage 02 run that never froze, the probe emitted **27 lines,
all of them the same pair**:
```
w> F800004C [wait-probe] thread F800004C has timed out N times in a row on
object BE56BB5C (type 2), timeout=18446744073709251616
```
— one thread polling one **Event** (`XObject::Type` 2) at guest VA `BE56BB5C`
with a relative timeout of `-300 000` × 100 ns ≈ **30 ms**. That is a legitimate
poller, not a symptom, and its streak reached 8 000 while the game was running
perfectly.
🔴 **Corrected before it became folklore:** the cvar's help text first claimed the
probe is *silent* on a healthy run. It is not — it is *quiet*, and one poller
dominates. The freeze signal will therefore be the **appearance of a new
(thread, object) pair**, not the presence of output.
**Not settled:** the freeze did not reproduce in this run, so there is no frozen
sample to compare yet. That is the whole of the next step, and the instrument and
its control are now in place for it.