145046f88f
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.
2.6 KiB
🔴 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:
#[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 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.