Files
LithosAnanake/logs
Robert Allan JamesandClaude Sonnet 5 70421bdd43
Build / build-amd64-iso (push) Waiting to run
Build / build-aarch64-iso (push) Waiting to run
Build / build-riscv64-img (push) Waiting to run
Fix real WIREBIND crash: stale active-VM pointer dispatched after blocking read (FABRIC-3.md §XII.3)
The interpreter_enabled guard added in the previous commit (662ef44) was a
real but incomplete fix -- re-running the exact repro against it still
panicked (this time as a raw #PF page fault), proving something deeper
was wrong.

Root cause, found via targeted console_puts probes (not GDB --
starkernel_kernel.elf's symbols don't correspond to the actual running
starkernel_loader.efi binary for this monolithic build, same gotcha
already on record from the 2026-08-18 aarch64 investigation):

sk_repl_run()'s main loop captures `active` once, before calling
sk_console_readline(), which then blocks for the next full line. If the
identity `active` points at is killed while that read is still blocked,
the bailout meant to catch this (sk_console_identity_present()) only
checks a generic "is anyone attached" boolean, not "is the specific
identity active belonged to still attached" -- a fast detach of one
identity followed by attach of a different one never produces an
observable gap in that boolean, so the bailout never fires. The stale
`active`, now pointing at freed memory, gets dispatched into.

Fix: re-resolve `active` fresh from g_repl_active_vm immediately before
dispatch, right after sk_console_readline() returns. One line, no
registry lookup, no dereference of the stale pointer -- closes the race
regardless of whether the bailout catches it first.

Verified: rebuilt amd64 clean, reproduced the exact same attach/USE/
detach/attach/USE sequence against the fixed build -- clean switch, no
fault, exerciser runs correctly afterward.

FABRIC-3.md §XII.2 also corrected to stop claiming the interpreter_
enabled guard alone closed the crash -- it didn't, per the above.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXieurDfDSsDFdnSyusuWo
2026-09-10 17:19:01 -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).