The doc claimed 181e8e36 showed a renderer and a GPU dying together "in the same
tree", and read that as a whole-cgroup kill. Measured from the payload they are
9m 04.9s apart — GPU process_gone_suppressed at 22:29:32.397Z, renderer report
Created at 22:38:37.276Z — so they are two independent single-process kills.
systemd-oomd is likewise demoted from explanation to candidate: it kills the
whole cgroup, and Orca's main process survived and authored the report in all
three cases (processMetricsBrowserCount: 1 post-death). These fields exist to
DISTINGUISH the killers, not to ratify one chosen in advance. The same claim is
scrubbed from the PSI reader header and the PSI test's field-report note.
Mutation testing also found `total === undefined` in cgroupCeilingBelowHostRam
unfalsifiable on its own: deleting only that term left the suite green, while
deleting it together with `lowest < total` was caught. The new test fixes a
readable ceiling beside an unreadable MemTotal, which kills the isolated mutant.
The reader test doubles skipped every line that actually opens a file: with
resolveCgroupV2MemoryDir, readLinuxCgroupMemoryLimitFromSysfs and
readLinuxMemoryPressureStallFromProcfs each throwing on entry, all 306
crash-reporting tests still passed. Adds a pseudo-file seam (shared by both
modules, as the single reader already was) and tests the namespace mount-root
fallback, the root-cgroup rejection, the all-undefined silence and PSI's
absence.
pre-gone-host-memory.test.ts calls getSystemMemoryDetails('linux') with the real
readers live, so on a memory-capped or busy Linux runner its label assertion
reads the runner's own cgroup and fails; seams it like the new files do.
Corrects the doc's blanket "an absent row means could not measure": memory.max
reading `max` is also reported as an absent field, and CgroupCurrentMB is what
separates the two.
Three v1.4.200 field reports (2ea53f9c, ad185d76, 181e8e36) are Arch renderer
SIGKILLs with ~100% free swap and gigabytes of MemAvailable, and 181e8e36 lost
the GPU process to exit 9 in the same tree. The kernel OOM killer does not fire
with that headroom; systemd-oomd, default-enabled on Arch, kills a whole cgroup
on PSI memory stall instead. Nothing in the report could tell those apart, or
tell either from an outside kill, because /proc/meminfo is the entire Linux
memory story a report carried.
Read cgroup v2 memory.max/high/current and memory.events (oom_kill, max, high),
plus PSI some/full avg10/avg60 from /proc/pressure/memory and the cgroup's own
memory.pressure. Both flow through getSystemMemoryDetails, so the existing
pre-gone sampler carries them as systemMemoryPreGone* automatically: an oom_kill
counter stepping across the death proves the kernel did it, and an unchanged one
rules the cgroup out.
The Linux pressure signal no longer says 'mem-available' unconditionally — it
refines to 'mem-available-cgroup-capped' or 'mem-available-stalled'. Both keep
the family prefix, so no existing value changes meaning.
Both readers are platform-guarded, swallow every read failure, and stay silent
rather than emit a row of zeroes that would read as "measured, and unlimited".
m4air
Claude