docs: the stuck-wait control holds on a second run, and the freeze did not come
A second 25-minute Stage 02 run under --log_stuck_waits ended NO FREEZE within 1500s, with the probe again reporting exactly one pair - thread F800004C on object BE56BB5C - 24 lines against the first run's 27. The healthy-run control is therefore measured twice and independently, so anything else the probe prints during a freeze is signal. Also recorded: two consecutive runs did not freeze, and the earlier freezes came in a cluster. Roughly half the runs that reached flight ended early across the session, but not evenly, so "wait for a freeze" is a ~30-minute lottery per run rather than a dependable step. Instrument, watcher and control are in place; one frozen sample is what is missing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
This commit is contained in:
@@ -369,3 +369,22 @@ dominates. The freeze signal will therefore be the **appearance of a new
|
||||
**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.
|
||||
|
||||
### 2026-08-24 — the control holds on a second run; the freeze did not come
|
||||
|
||||
A second Stage 02 run with `--log_stuck_waits=true`, watched end to end by
|
||||
[`freeze_watch.sh`](../../tools/re-capture/freeze_watch.sh):
|
||||
**`NO FREEZE within 1500s`** — about 25 minutes of flight, and the probe again
|
||||
reported exactly **one** pair, `thread F800004C on object BE56BB5C (type 2)`,
|
||||
24 lines against the first run's 27.
|
||||
|
||||
So the healthy-run control is now measured **twice, independently**, and it is
|
||||
the same single legitimate poller both times. Anything else the probe prints
|
||||
during a freeze is signal.
|
||||
|
||||
🟡 **And the cost of catching one is worth stating.** Two consecutive runs did
|
||||
not freeze; the freezes earlier in the day came in a cluster. Across the session
|
||||
roughly half the runs that reached flight ended early (freeze or GAME OVER), but
|
||||
they are **not evenly distributed**, so "wait for a freeze" is a ~30-minute
|
||||
lottery ticket per run rather than a reliable step. The instrument, the watcher
|
||||
and the control are all in place; what is missing is one frozen sample.
|
||||
|
||||
Reference in New Issue
Block a user