Commit 813c3962 by PLN (Algolia)

log 047: the same bug twice in one morning, writer changed and reader lied

Coda on the reader patches, plus the measurement worth keeping: scsynth sits at oom_score_adj=200, penalised rather than merely unshielded, which is the real argument for getting protect back on.
parent d1d7298e
...@@ -74,3 +74,37 @@ it will drift, and the drift shows up as false confidence rather than as an erro ...@@ -74,3 +74,37 @@ it will drift, and the drift shows up as false confidence rather than as an erro
"I fixed the preload and it went from 132 sample banks to zero. Then the checker "I fixed the preload and it went from 132 sample banks to zero. Then the checker
told me everything was fine — and *that* was the real bug." told me everything was fine — and *that* was the real bug."
---
## Coda, same morning: the identical bug one file over
While reviewing the `fix-ardour-rt.sh` dry run before applying it, the same shape
turned up in the Ardour work. Four patches correctly stopped **both writers** from
promoting Ardour's GUI thread to `SCHED_FIFO/80`. Nothing patched the **readers**:
- `parvagues-protect --check` demanded `SCHED_FIFO` of every target, so an Ardour
deliberately left on `SCHED_OTHER` would have read `UNPROTECTED` forever, and
`check()`'s exit code is what the gate, the Bridge and gig-up believe. A correct
rig would have shown a red Ardour all night, burying the one question worth
asking: *is scsynth actually covered?*
- `perf-audio` kept printing `✓ Set Ardour (PID …) to real-time priority 80`, and
the same for every child, while deliberately doing neither.
Fixed in `06352a9`: `check()` reads the target's own prio out of its `TARGETS` row,
so prio 0 means "want the OOM shield, leave scheduling alone". Verified on copies —
8/8 verdict truth table, both files `bash -n` clean, second `--apply` idempotent —
and then against the live processes, where the patched checker prints
`ok ardour[615285] oom_score_adj=-1000 sched=SCHED_OTHER (oom shield only, by
design)` and still flags scsynth and sclang, which are genuinely uncovered while
protect is off.
**Twice in one morning, in unrelated code: the writer changed and the reader kept
asserting the old truth.** The preload version invented an all-clear; this one would
have invented a fault. Both are the same defect wearing opposite clothes, and both
were found by reading the thing that judges the change rather than the change.
One measurement worth keeping from that run: **scsynth is sitting at
`oom_score_adj=200`**. Not merely unshielded — *penalised*, i.e. first in line for
the OOM killer on the whole box. That is the real argument for getting
`parvagues-protect` back on, and it is invisible unless something asks.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment