tests/process_cpu.rs (macOS) starts a child that spins `while :; do :; done` and kills it
inside the window it meters. Between its spawn and that kill each energy read asserts; a read
that failed there unwound past a bare std::process::Child, which is not killed when it is
dropped, and left the child spinning a core once the test binary had ended, one more for each
failed run. The child is now held, as it is spawned, in a `Running` that kills it and reaps it
when it is dropped, waiting up to 10 s (as wai-quantum-service's tests hold theirs, 04d19cfd8);
the test still kills and reaps it inside the window, so what it meters is unchanged.
Planted fault, on the old-prod Mac Studio (macOS, M3 Ultra): the test made to panic right
after its first read of the child's counter, with the child running, run alone in a session and
process group of its own (POSIX setsid; macOS has no setsid command, and its ps and pgrep
cannot select by session, so the group was listed), 3 s after cargo ended. At main the group
held the busy child (/bin/sh -c while :; do :; done, 3 s old), which was then killed by its
group; with the guard it held nothing.
Gates, on the old-prod Mac Studio: cargo test --locked -p jouleclaw-energy passed (76 tests in
9 binaries) and with --features ioreport (144 in 9), each leaving nothing in its process group;
cargo clippy --locked --all-targets --no-deps -p jouleclaw-energy -- -D warnings is clean in
the default build and with ioreport. The light checks pass.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
b2e75b9f37