fix(test): open sound.pak once, not once per call #58

fabi · 2026-09-19T14:59:28Z

fabi commented

2026-09-19 14:59:28 +00:00

Found by actually running the documented baseline on fabi-Hyrican-PC: it does not reproduce. cargo exits 101, and the run reports 44 suites / 367 passed / 0 failed against the documented 45 / 377 / 0.

The failure mode is the interesting part

slb_leading_segment_disc was SIGKILLed (signal 9) — the OOM killer. ⚠️ A killed suite prints no test result: line at all, so it does not fail visibly, it disappears from the tally. The run still said 0 failed — true, and completely useless. The only honest signal is cargo's exit code.

That also explains the arithmetic exactly: 367 + 10 = 377, 44 + 1 = 45.

Cause, measured

PakArchive holds the entire concatenated payload in memory, and sound.pak is 1.01 GB (sound.p00–.p04):


one open	1.01 GB
× 6 default test threads	6.08 GB
container cap	7 GB, `--memory-swap` == `--memory`, so no swap

bank() and bank_named() opened the archive on every call, inside loops, and five more tests opened their own — ~26 opens for a suite of 10 tests.

Fix

One OnceLock archive for the binary. It is immutable once open and every accessor takes &self, so one shared instance is equivalent to N private ones at 1/N the memory.

Measured in the capped container, 7 GB, default threads

	result
before	SIGKILL, 0 of 10 tests reported
after	10 passed in 3.17 s ✅
single-threaded before the fix	10 passed in 22.64 s
`cargo fmt --check`	clean ✅
`cargo clippy --tests -D warnings`	clean ✅

The ~7× speed-up is a side effect: it no longer re-reads 1 GB from disc 26 times.

Why it matters beyond this box

It makes the baseline reproducible at the default SYLPH_CI_MEM_GB=7 instead of needing the 31 GB machine's =14, and removes a suite that could silently vanish from any future run.

Found by actually running the documented baseline on `fabi-Hyrican-PC`: it **does not reproduce**. `cargo` exits **101**, and the run reports **44 suites / 367 passed / 0 failed** against the documented 45 / 377 / 0. ### The failure mode is the interesting part `slb_leading_segment_disc` was **SIGKILLed (signal 9)** — the OOM killer. ⚠️ **A killed suite prints no `test result:` line at all**, so it does not fail visibly, it *disappears from the tally*. The run still said `0 failed` — true, and completely useless. The only honest signal is cargo's exit code. That also explains the arithmetic exactly: 367 + 10 = 377, 44 + 1 = 45. ### Cause, measured `PakArchive` holds the entire concatenated payload in memory, and `sound.pak` is **1.01 GB** (`sound.p00`–`.p04`): | | | |---|---| | one open | 1.01 GB | | × 6 default test threads | **6.08 GB** | | container cap | 7 GB, `--memory-swap` == `--memory`, so no swap | `bank()` and `bank_named()` opened the archive on **every call, inside loops**, and five more tests opened their own — ~26 opens for a suite of 10 tests. ### Fix One `OnceLock` archive for the binary. It is immutable once open and every accessor takes `&self`, so one shared instance is equivalent to N private ones at 1/N the memory. ### Measured in the capped container, 7 GB, default threads | | result | |---|---| | before | **SIGKILL**, 0 of 10 tests reported | | after | **10 passed in 3.17 s** ✅ | | single-threaded before the fix | 10 passed in 22.64 s | | `cargo fmt --check` | clean ✅ | | `cargo clippy --tests -D warnings` | clean ✅ | The ~7× speed-up is a side effect: it no longer re-reads 1 GB from disc 26 times. ### Why it matters beyond this box It makes the baseline reproducible at the default `SYLPH_CI_MEM_GB=7` instead of needing the 31 GB machine's `=14`, and removes a suite that could silently vanish from any future run.

fabi added 1 commit 2026-09-19 14:59:28 +00:00

fix(test): open sound.pak once, not once per call

CI / Native — linux (pull_request) Successful in 2h25m14s

Details

CI / WASM — Web (pull_request) Successful in 33m41s

Details

CI / Formatting (pull_request) Successful in 1m42s

Details

731acffaa9

`slb_leading_segment_disc` was SIGKILLed by the OOM killer in `docker/ci/run`
at its 7 GB cap, so the documented 45/377 baseline did not reproduce on a 15 GB
box.

`PakArchive` holds the whole concatenated payload in memory and `sound.pak` is
1.01 GB (sound.p00-.p04). `bank()` and `bank_named()` opened it on every call --
inside loops -- and five tests opened their own besides, ~26 opens in all. With
cargo's default thread count that is ~6.1 GB of archive in flight against a
7 GB cap with `--memory-swap` equal to `--memory`, so there is no swap to
absorb it.

The archive is immutable once open and every accessor takes `&self`, so one
`OnceLock` instance is equivalent to N private ones at 1/N the memory.

⚠️ The failure mode is worth knowing: a SIGKILLed suite prints no
`test result:` line at all, so it disappears from a scraped tally instead of
failing visibly. The run still reported "0 failed" -- true, and useless. Check
cargo's exit code (101), not the tally.

Measured in the capped container, 7 GB, default threads:
  * before: SIGKILL (signal 9), 0 of 10 tests reported
  * after : 10 passed in 3.17s
  * (single-threaded before the fix: 10 passed in 22.64s -- the fix is also
     ~7x faster, because it no longer re-reads 1 GB from disc 26 times)
  * cargo fmt --check clean; cargo clippy --tests -D warnings clean

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

fabi merged commit d6fb31690a into main

2026-09-19 18:48:28 +00:00

fabi referenced this issue from a commit

2026-09-19 18:48:30 +00:00

Merge pull request 'fix(test): open sound.pak once, not once per call' (#58) from fix/slb-suite-one-archive into main

fabi referenced this issue from a commit

2026-09-19 20:29:49 +00:00

Merge pull request 'fix(test): open sound.pak once, not once per call' (#58) from fix/slb-suite-one-archive into main

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: fabi/Sylpheed#58