3 Commits

Include renames

Author	SHA1	Message	Date
Robert Allan JamesandClaude Opus 5.5	27c430e0ca	Stage K-1: real kernel realloc; word-metrics defects closed (FABRIC-3.10.8 §4.1) ... - Kernel sf_realloc() is a real realloc (copy min(old,new) via new kmalloc_usable_size(), free old, NULL-on-0 frees). It allocated fresh and nothing else: every growth leaked, and vm_state_push()'s call-state stack lost every saved state past depth 8 (found here). - Shim realloc() copies min(old,new) (over-read when growing). - Defect 9: FC bucket growth no longer leaks or patches a copy; no sf_xrealloc() (freed a block the index still held on failure). - Defect 5: heat snapshot heap-sized (was heats[1024], truncating). - Defect 6: word refused whole when its metrics can't be allocated. - Defect 7: vm_cleanup() (both) frees metrics' inner arrays. - Defect 8: most-likely-next kept incrementally; no full id scan. - Probe (removed): realloc keeps contents, heap returns exactly; call stack depth 20 intact; all three ISAs. Churn criterion NOT met: ~7 KB retained per churned VM (quota slots/word rows -- K-4 re-measures); a post-churn CONSOLE-CMD refusal attributed to the quota leak, K-4 retests. - Standard sequence on amd64/aarch64/riscv64: hashes, G, ledger unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-26 02:30:43 -04:00
Robert Allan JamesandClaude Sonnet 5	9142dda2d6	Fix use-after-free in sk_repl_idle()'s idle-tick VM resolution (FABRIC-3.md §XIII) ... Root-caused a heap-corruption bug that reliably failed WIREBIND identity attach on the third attach/detach cycle in one boot. sk_console_readline() and sk_console_getkey() captured `active_vm` once from their caller and kept passing that same (possibly long-stale) pointer to sk_repl_idle() on every idle tick serviced while blocked waiting for input. If the VM it pointed at was killed (WIREBIND detach) mid-block, the existing bailout only checked a generic "is anyone attached" boolean -- masked as soon as a different identity attached next -- so blk_vm_flush_all() kept writing into a freed VM struct sitting on kmalloc's own free list, corrupting the free list's linked-list metadata itself. Both idle branches now re-resolve the live active VM fresh from g_repl_active_vm on every tick, matching the dispatch-side fix already made for the sibling bug in §XII.3. Verified: rebuilt amd64, reran the exact three-cycle repro that reliably corrupted the heap before the fix -- free-list census stayed stable through the same idle window that previously collapsed to zero. All three architectures (amd64/aarch64/riscv64) boot clean to the zuse)ok> prompt. kmalloc_debug_census()/kmalloc_debug_census_bytes() kept as permanent diagnostic infrastructure; every other temporary probe added during the investigation was reverted. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EXieurDfDSsDFdnSyusuWo	2026-09-10 20:30:41 -04:00
Robert Allan James	a5ed8c3d87	Initial commit — LithosAnanke kernel	2026-08-01 07:49:56 -04:00