0efd692b4c
Last iteration I wrote that build-reborn test cannot finish in a working session, from having watched it run 3h26m. That was the stronger claim and I made it without measuring the work. Timing `mesh info` on each of the 166 .xpr containers with a 25 s cap: files scanned 166 exceeding 25 s 19 Hangar, 17 Stage_*, ptc_pack Stage_S02 to completion 144 s, rc = 0 Nothing hangs. Nineteen heavy containers at roughly two minutes each is about 45-60 minutes for one pass, before the 147 fast ones. The 3h26m observed was that hour of work running at a load average of 9-14 -- inflated by the two duplicate runs I had left going, which did not merely coexist with the slowness but multiplied it. The practical conclusion is unchanged and only the wording softens: an hour-scale suite is not an iteration-scale gate, and every "green" I reported from it this session was partial. But an hour-scale gate can be run deliberately, whereas a hung one cannot be run at all, so the distinction is worth having right. File list committed as reference data so the cost is attributable without re-scanning. METHOD: a slow thing observed under contention looks like a stuck thing; measure the work before choosing between "cannot finish" and "takes an hour".
3.5 KiB
🟡 build-reborn test takes about an hour — 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.
🔴 "Cannot terminate" was too strong — corrected
It terminates; it is merely heavy, and I said the stronger thing before measuring
it. Timing sylpheed-cli mesh info on each of the 166 files with a 25 s cap
(data/slow-xpr-files.txt):
| files scanned | 166 |
| exceeding 25 s | 19 — Hangar, 17 Stage_*, ptc_pack |
Stage_S02 timed to completion |
144 s, rc = 0 |
So nothing hangs. Nineteen heavy containers at roughly two minutes each is ~45–60 minutes for one pass, before the 147 fast ones. The observed 3 h 26 m was that work running at a load average of 9–14 — inflated by my own two duplicate runs competing with each other and with this one. The runaways did not merely coexist with the slowness; they multiplied it.
⚠️ The practical conclusion is unchanged and only the wording softens: an
hour-scale suite is not an iteration-scale gate.
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.