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

re: my own probe is now the strongest freeze correlate

Browse Source 
phase_watch.py runs give a sharper tally than the earlier inducer test, because
the only difference between the groups is one tool: pilot alone went clean to
936s and 1064s (2 runs), while pilot + phase_watch froze at ~70s, ~253s and
~126s (3 runs). Same boot path, same pilot, same mission.

What phase_watch adds is find_mission(), which does TWO full sweeps of guest
memory at startup plus ~130 small reads every 5s. The sweeps are the same shape
as the heavy_read.py scans the earlier n=2 experiment implicated.

Still correlation, not cause -- 3 vs 2, and the earlier inducer test produced a
clean counter-example. But it is the best-supported version of 'the instrument
provokes the freeze' so far, and it is my instrument, which makes it actionable.

The cheap test is named: find_mission only needs to run once, so re-run the
watch with the sweeps replaced by an address from a prior run. Freezes stopping
implicates the sweeps; continuing implicates the per-sample reads.

Cost so far: three attempts at observing a phase advance, all truncated inside
four minutes.
This commit is contained in:
Sylpheed RE agent
2026-08-25 15:19:52 +00:00
parent 18a5a51c3d
commit 4e46ae0b42
1 changed files with 35 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -1182,3 +1182,38 @@ thread identity or behaviour carries across runs for free.
**Net for the distribution experiment:** the healthy half now has two independent
samples; the frozen half is **still uncollected**, because run 3 never froze.
## 🟡 2026-08-25 — my own probe is now the strongest freeze correlate
The `phase_watch.py` runs give a much sharper tally than the earlier
inducer experiment did, because the difference between the two groups is a
single tool:
| probe attached | runs | outcome |
|---|---|---|
| pilot only | 2 | **clean to 936 s and 1064 s** |
| pilot + `phase_watch.py` | **3** | **froze at ~70 s, ~253 s, ~126 s** |
Five runs, same boot path, same pilot, same mission. Every run carrying the
script probe froze inside ~4 minutes; neither run without it froze in ~16.
**What `phase_watch` does that the pilot does not:** `find_mission()` performs
**two full sweeps of guest memory** at startup — one for the `.ssb` header, one
for every word equal to the code base — and then ~130 small reads every 5 s. The
full sweeps are the obvious suspect, and they are the same *shape* as the
`heavy_read.py` scans that the earlier n=2 experiment implicated.
⚠️ **Still correlation.** Three-versus-two is suggestive, not causal, and the
earlier inducer test already produced one clean counter-example when the box was
loaded. But it is now the best-supported version of "the instrument provokes the
freeze", and it is *my* instrument, which makes it actionable rather than
academic.
**The cheap test:** `find_mission` only needs to run once, and its result could
be passed in on later samples — so run the same watch with the sweeps replaced by
a hard-coded address from a prior run. If the freezes stop, the sweeps are the
cause; if they continue, the per-sample reads are.
**Cost so far:** three attempts to observe a phase advance, all truncated inside
four minutes by a freeze the probe itself may be causing. The arrival transition
at ~143 s was caught only because it happens early.