Files
LithosAnanake/logs
Robert Allan JamesandClaude Sonnet 5 d8a195b8d8 WIREBIND: kill the orphaned console VM when the user VM birth fails
Found live during identity-heap-capacity testing (2026-09-07,
hotplugging Zuse + 8 identities one at a time and measuring the kernel
heap arena via a temporary allocator-stats probe, since reverted): every
WIREBIND identity attach births two VMs in sequence -- a "console" VM,
then the real "user" VM. When the second birth failed (arena
fragmentation under concurrent VM load, a separate, not-yet-fixed
capacity issue), capsule_wirebind_try_attach() logged the failure and
returned, but the console VM that had *already succeeded* was never
torn down. It stays live and registered under the identity's username,
consuming its own ~228KB of the fixed 4MB kernel heap arena forever --
nothing ever points a real user at it, since WIREBIND only ever hands
the caller the user VM's id.

This turns every failed identity attach into a permanent net loss of
heap rather than a neutral retry: confirmed live that a failed attach
left the arena 228,576 bytes worse off than before the attempt, and
every subsequent attempt starts from that worse baseline, compounding.

Fix: call capsule_vm_kill(username) on the now-orphaned console VM
before returning from the failure path -- the same teardown
capsule_wirebind_eject()/capsule_wirebind_unclean_detach() already use
elsewhere in this file (vm_cleanup() + sf_free(), confirmed live to
actually reclaim per-word dictionary allocations, FABRIC-3.md
§IX.2/§IX.3).

Verified live with the same allocator-stats probe (written, captured,
reverted -- not part of this commit): after the fix, a forced user-VM
birth failure now returns the arena to exactly its pre-attempt byte
count (3,526,256, matching the baseline precisely) instead of leaking
228,576 bytes. Three-arch clean qemu acceptance (single Zuse device,
the standard regression case) passed on amd64, aarch64, and riscv64.

The underlying capacity/fragmentation question (why the 7th concurrent
identity's arena allocation fails at all despite technically-sufficient
free bytes) is a separate, open architecture question -- not addressed
here. See project memory for the full measured numbers.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Ec88YKxxhZGG1RNnune78
2026-09-07 11:37:06 -04:00
..
2026-08-02 05:11:24 -04:00
2026-08-02 05:11:24 -04:00
2026-08-02 05:11:24 -04:00
2026-09-01 12:09:20 -04:00
2026-09-01 12:09:20 -04:00

logs/

QEMU acceptance-run history and Tripod smoke-test results.

  • <timestamp>/{amd64,aarch64,riscv64}/ — 255 timestamped three-arch QEMU acceptance run directories, one per invocation of the kernel QEMU acceptance workflow.
  • qemu-screenshot-*.png, qemu-screenshot-*.log, qemu-{amd64,aarch64,riscv64}-*.log, fbtest-console-*.png — loose timestamped QEMU serial captures and framebuffer screenshots from individual manual runs (not part of the timestamped-directory convention above).
  • hermes-tripod-smoke-results.md, hermes-channel-smoke-results.md — captured output from tools/hermes_tripod_smoke.sh and tools/hermes_channel_smoke.sh.
  • hermes-tripod-integration-design.md — design notes for the Tripod integration test.

Note: QEMU_BASELINE.log at the repo root (not in this directory) is the primary kernel regression baseline referenced by .claude/CLAUDE.md; the logs here are supplementary historical captures. See also logs2/ (a separate, flatter QEMU log archive) and experiments/bare_metal/runs/ (DoE-specific run output).