Findings: task 3.8 payload-aliasing defect found while starting 3.9
While orienting for task 3.9 (CONSOLE-CMD-EVENT cutover, per Captain Bob's ruling to verify via a real QMP/serial-socket console session), booting with a second real identity drive attached alongside Zuse's own exposed a real defect in the already-closed task 3.8 code: g_kh_blk_attach_buf (repl.c) is one static buffer, and sk_hermes_send_one() stores payload_addr as a caller-owned pointer, not a copy. Two real USB-MSC attaches in one sk_repl_idle() pass send before either drains, so both messages alias the same buffer -- only one identity ever completed. Task 3.8's own write-up claimed this "carries the same single-buffer- reuse shape ATTACH-ACK-BUF itself already had... not a new hazard" -- that claim was wrong and is amended in FABRIC-3.6.md's findings log. FORTH's own MSG-SEND had the identical pointer-aliasing shape but never hit the window: MSG-TICK drained from the same sk_repl_idle() pass that queues attaches. Kernel-Hermes drains at interpret checkpoints, which don't fire during that pass at all -- the cutover changed not just how delivery happens but when, opening a window FORTH's own design never had. Reported, not fixed here, per Captain Bob's Law: this is a defect in closed task 3.8 code, found while scoping a different task. A real fix changes SkHermesMessage's own shape to own its payload bytes rather than reference a caller's pointer -- bigger than a repl.c patch, touches every existing sender, needs its own three-ISA acceptance. Task 3.9's own send-side cutover (kernel_hermes.h, repl.c) is written but deliberately left uncommitted -- it would inherit the identical defect shape if shipped now. logs/20260922-111840/amd64/ is the reproduction. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Sonnet 5
parent
bbfd9103f4
commit
7944abca36