From 21771fc765761590f4d27b03f8968dbf9ee0b5f4 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Sat, 29 Aug 2026 03:45:14 +0000 Subject: [PATCH] docs: the verification gate cannot terminate, and I left two runs going 4h Two findings from checking whether last iteration's partial green had finished. It had not, and the reason matters for anyone using the gate. build-reborn test contains twin_pairs_do_not_share_a_buffer, which decodes every .xpr in hidden/resource3d -- 166 files, 1.4 GB -- through the full Xbg7Model anchoring path, and is NOT #[ignore]d. Its sibling in the same file walks the same 166 files and IS ignored as known-failing, which makes the binary's cost easy to underestimate. Measured: one instance accumulated 3h26m of CPU at 89% without finishing. So every "green run" reported in this corpus from a workspace or sylpheed-formats test is necessarily PARTIAL unless it says the suite terminated -- including the ones I reported this session. The honest form is the suite count and elapsed state, not the word "green". Not proposing to #[ignore] or subsample it: that changes what the suite asserts and is the project's call, not an audit side-effect. And the mess is mine. Two cargo test -p sylpheed-formats runs launched detached in earlier iterations never exited, because they were sitting in that test: pid 103375 4h12m elapsed child mesh_consistency_disc 3h26m CPU 89.3% pid 99965 4h39m elapsed child pak_idxd_disc 1h16m CPU 93.8% Load average 14.18 on 12 cores. Killed, after checking the legitimately running workspace suite and leaving it alone; load fell to 9.68. What this does NOT explain, because it is tempting: the session's emulator troubles. screenshot cost 0.49 s with both runaways live and the emulator stopped, against 10.8 s measured earlier with the emulator running. The 92x figure really was emulator contention; the runaways were a background tax on top. The black surface and the unreachable title stand as measured, with their own controls. METHOD: a detached job you never check can outlive many iterations -- setsid was added so a timeout could not kill them, which also means nothing does; and know whether your verification gate can terminate. --- docs/re/METHOD.md | 13 ++++++++ docs/re/test-suite-runtime.md | 57 +++++++++++++++++++++++++++++++++++ 2 files changed, 70 insertions(+) create mode 100644 docs/re/test-suite-runtime.md diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md index 8ecda09a..736d2604 100644 --- a/docs/re/METHOD.md +++ b/docs/re/METHOD.md @@ -721,3 +721,16 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the version grepped for the doc's formatting (`14 709` with a thin space, `33.7` rounded from `33.66`) and reported almost every figure as a mismatch. A consistency check that fails on formatting will train you to ignore it. +* **A detached job you never check can outlive many iterations.** Two + `setsid nohup cargo test … &` runs from earlier iterations were still alive + **four hours** later, one child at 89 % CPU for 3 h 26 m, holding the load + average at 14 on 12 cores. `setsid` was added precisely so a tool-call timeout + could not kill them β€” which also means nothing kills them. Check that a + backgrounded run actually exited before launching the next one, and prefer + `ps -o etime=` over assuming. +* **Know whether your verification gate can terminate.** `build-reborn test` + includes a disc test that decodes 166 `.xpr` files (1.4 GB) and had not + finished after 3 h 26 m of CPU. Every "green run" from it is partial unless the + suite is stated to have terminated β€” so report the suite count and elapsed + state rather than the word "green", which is what I should have been doing all + session. diff --git a/docs/re/test-suite-runtime.md b/docs/re/test-suite-runtime.md new file mode 100644 index 00000000..01792500 --- /dev/null +++ b/docs/re/test-suite-runtime.md @@ -0,0 +1,57 @@ +# πŸ”΄ `build-reborn test` cannot finish in a working session β€” and I left two runaways + +**Status:** βœ… measured. Two facts, one of them my own mess. + +## The gate the brief names does not complete + +`build-reborn test` (`cargo test --workspace` with `SYLPHEED_DISC` wired up) is +the verification gate. It contains a disc test that decodes **every `.xpr` in +`hidden/resource3d` β€” 166 files, 1.4 GB** β€” through the full `Xbg7Model` +anchoring path: + +```rust +#[test] // NOT #[ignore]d +fn twin_pairs_do_not_share_a_buffer() { + …for f in &files { … Xbg7Model::anchor_models_cancellable(&bytes, 0.0, &|| false) … } +``` + +Measured: one instance accumulated **3 h 26 m of CPU at 89 %** without finishing. +Its sibling in the same file, `shared_resources_decode_identically_in_every_container`, +walks the same 166 files and *is* `#[ignore]`d (as known-failing), so the binary's +cost is easy to underestimate from a glance at the file. + +⚠️ **Consequence for anyone using this gate:** every "green run" reported in this +corpus from a workspace test is necessarily **partial** unless it explicitly says +the suite terminated. `cargo test -p sylpheed-formats` reaches ~131 tests in a few +minutes and then sits in this one; the workspace run is the same picture. Quote +the suite count and the elapsed state, not the word "green". + +🟑 Not proposed here: `#[ignore]`-ing it, or bounding it to a sample of the 166. +Both change what the suite asserts, which is the project's call and not a +side-effect of an audit. + +## πŸ”΄ And I left two of them running for four hours + +Two `cargo test -p sylpheed-formats` runs launched detached in earlier iterations +never exited, because they were sitting in this test. At the moment they were +found: + +| pid | elapsed | child | CPU time | %CPU | +|---|---|---|---|---| +| 103375 | 4 h 12 m | `mesh_consistency_disc` | **3 h 26 m** | 89.3 | +| 99965 | 4 h 39 m | `pak_idxd_disc` | 1 h 16 m | 93.8 | + +Load average **14.18** on 12 cores. Killed; load fell to **9.68** within a +minute, and the legitimately-running workspace suite was checked first and left +alone. + +### πŸ”΄ What this does NOT explain + +It is tempting to pin the session's emulator troubles on this, and the +measurement says no. `screenshot` cost **0.49 s** with both runaways live and the +emulator stopped, against the **10.8 s** measured earlier with the emulator +running. So the 92Γ— figure in +[capture-harness-status](capture-harness-status.md) really was emulator +contention, and the runaways were a background tax on top β€” not the cause. The +black surface and the unreachable title stand as measured, with their own +controls.