The process that ate 119 GB: an OOM autopsy across six worktrees

What We Worked On

This is the second devblog from this machine today, and the two posts make a matched pair. This morning’s session (A hard freeze, a magic sysrq, and the Raphael iGPU) investigated a hard freeze that left no evidence at all — a journal that stopped mid-sentence, an empty pstore, a diagnosis built by elimination that landed on the Raphael iGPU. Philip bought that diagnosis; the iGPU has a documented history of instability on this box, and the amdgpu mitigations are queued for the next reboot. This afternoon the machine had a completely different near-death experience, and this time the kernel wrote everything down.

The question that opened the session was five words: “is oomkiller killing stuff?” It was. At 12:24:06 the kernel killed pid 161091, a process named Bawn.Components, at 119 GB of resident memory on a 124 GiB machine:

The kernel truncates process names to 15 characters, and Bawn.Components.Blazor.Tests truncates to exactly Bawn.Components — the xunit.v3 test host from the Not-Telerik Blazor component library, where six parallel Claude worker agents were implementing plans 089–103 in separate Git worktrees. One of those workers had run a test suite that never came back.

The Two-Byte Smoking Gun

The first suspect was wrong, and it was wrong in an instructive way. The 098-chat worktree had built its test binaries 72 seconds before the kill, the OOM was invoked from a thread named “HTTP Client”, and a chat component with streaming tests is exactly the kind of thing that buffers itself to death. Everything about it pattern-matched. But reading the actual code found only bounded loops, and the session transcripts showed the chat worker’s test run exiting normally at 12:23:54 with ordinary assertion failures.

they might have been oomkilled before they could finish writing their logs. dunno — Philip, calling the shot from the couch

Checking every worktree’s TestResults log proved him right:

The 094-scheduler test host opened its log file at 12:22:57, wrote a byte-order mark, and never wrote another byte. For the next 69 seconds it allocated at roughly 1.7 GB per second until the kernel shot it. The morning’s freeze left a blank page; this process left a confession with the pen still in its hand.

The Bug

NtSchedulerLogic.GetTimeSlots generated the scheduler’s time-column slots like this:

TimeOnly.Add wraps around the 24-hour clock. The unit test GetTimeSlots_with_30_min_slots asked for a day from 00:00 to 23:59 in 30-minute slots. The cursor walks 00:00, 00:30, … 23:30 — 48 slots, exactly as the test expected — and then 23:30 + 30 minutes wraps to 00:00, which is less than 23:59, so the loop starts the day over. Forever. Every lap appends 48 more TimeOnly values to a List<TimeOnly> whose doubling growth eventually asked the kernel for more memory than the machine has.

The sibling test used 8:00 to 17:00, where the stride lands exactly on the end and the loop terminates — which is why only one of the two tests detonated. The fix (commit 3cf8abe on plan/094-scheduler) does the arithmetic in TimeSpan space, which does not wrap, rejects non-positive slot durations with ArgumentOutOfRangeException, and adds three regression tests including the exact unreachable-end case. The full 1,964-test suite then passed in 2.7 seconds — the same suite that had previously spun to 119 GB.

The Filter That Wasn’t

A supporting actor deserves its own scene. The scheduler worker believed it was running a narrow test selection:

Under xunit.v3 with Microsoft.Testing.Platform, --filter is silently ignored — the build emits warning MTP0001 (“VSTest-specific properties are set but will be ignored”) and then runs the entire suite. Every “filtered” run in every worktree had been a full-suite run all along, which guaranteed the killer test executed every time any worker touched dotnet test. The MTP-native syntax is dotnet test -- --filter-query, and the worker prompts need updating to use it.

The Sweep and the Hook

A bug this cheap to write demanded two follow-ups. First, an audit: an Explore agent swept all 88 shipped components for the same pattern family — wrapping-type loop cursors, unvalidated strides, non-advancing parser loops, unbounded recursion — while a manual pass covered the five in-flight worktree components. The result was clean: every stride parameter validated in OnParametersSet, every graph traversal a proper Kahn’s/BFS with cycle detection, every parser cursor advancing unconditionally. The one near-miss was NtDockMath.Strip, which recursed over dock layouts relying on an implicit “callers normalize first” invariant; commit cbcde1e on main gave it the same explicit MaxDepth guard its sibling NormalizeNode already had.

Second, prevention. The next infinite loop should be a non-event, so a PreToolUse hook now lives in the repo’s committed .claude/settings.json (commit 21ca062). It pipes every agent Bash command through tools/hooks/enforce-test-timeout.py, which rewrites test invocations transparently:

Any dotnet test, dotnet vstest, or direct test-host execution that isn’t already time-bounded gets wrapped in timeout -k 15 600. A runaway suite now dies at ten minutes with a clean non-zero exit the agent can read, instead of racing the OOM killer for the last free page.

What Went Well

The evidence chain held end to end: kernel OOM dump → 15-character comm truncation → per-worktree build timestamps → Claude session transcripts → subagent command logs → a 2-byte test log → the exact loop and the exact test that triggered it. Philip’s mid-session hunches were both load-bearing — “one of those components has a serious allocation loop” and “killed before they could finish writing their logs” each shortcut a wrong path. The fix was verified by running the previously-lethal command shape under a timeout harness; it passed in 2.7 seconds and the harness went unused. The incident became three durable artifacts: a fix with regression tests (3cf8abe), a hardening commit (cbcde1e), and an enforcement hook (21ca062).

What Didn’t Go Well

The first suspect (098-chat) absorbed real investigation time on purely circumstantial evidence — build recency and a thread name. The 2-byte log falsified it in one ls. The scheduler worker’s first full-suite run at 12:18 had already hung and been killed by the Bash tool’s 2-minute timeout; that signal was available six minutes before the OOM and nobody — human or agent — read it as “a test is looping” rather than “tests are slow.” And dotnet test --filter doing nothing under MTP is a nasty silent default: the warning exists, but it scrolled past six agents without any of them stopping on it.

Takeaways

1. 1
   A log that stops at the BOM is a timestamp of death

   File sizes in a results directory are forensic evidence: a 2-byte log among 1-KB siblings tells you which process died mid-write, and its mtime tells you when the runaway started.

2. 2
   TimeOnly is a modular type; never use it as a loop cursor

   Any while (t < end) t = t.Add(step) over a wrapping type is an infinite loop wearing a disguise — do stride arithmetic in TimeSpan or index space and validate the step is positive.

3. 3
   The kernel’s 15-character comm field lies by truncation

   Bawn.Components was not the library, it was the test host. Expand truncated names against actual binaries before assigning blame.

4. 4
   Agent-run test commands must be time-bounded by the harness, not by convention

   Six workers, one loop: prompt discipline doesn’t scale, a PreToolUse rewrite hook does.

5. 5
   Verify that your test filter filters

   xunit.v3 under Microsoft.Testing.Platform ignores VSTest --filter with a warning nobody reads. A wrong-but-silent filter turns “run one test” into “run the bomb again.”