DF-5765 -- third panic capture (from the first "fix-build" attempt) Provenance / honesty note: this capture is from a session intended to test a first fix revision. Post-hoc behavioral analysis PROVED the loaded module in that session still contained UNPATCHED (or partially patched) production code, because the fix under test (copyin-before-publish) makes successful opens during pure-EFAULT churn IMPOSSIBLE (verified: 3.4M racer attempts -> opens=0), yet this run shows successful opens (PROOF lines). Root cause of the mixup: build.sh ran `make` with MAKEOBJDIRPREFIX set, the follow-up rebuild ran without it, so a different objdir served stale objects. The session is therefore counted as a THIRD reproduction of the unpatched behavior, NOT as evidence about the fix. It is preserved because it contains the CLEANEST (non-interleaved) PROOF line of the dangling handoff: [xlatrace] 5 racers started [xlatrace] racer on cpu1 up (zz9to:zz9from) [xlatrace] racer on cpu2 done [xlatrace] racer on cpu5 done [xlatrace] racer on cpu1 done [xlatrace] racer on cpu4 done [xlatrace] racer on cpu1 up (zz9to:zz9from) [xlatrace] PROOF: live handle d_csp=0xfffff80116c2bae0 refcount=-2046 -- pair freed/reused under the open (d_table=0xfffff8008da91600) [xlatrace] PROOF: live handle d_csp=0xfffff80116c2bae0 refcount=-2046 -- papaniicr: fr eBeADdF/REreEu2s d cupnuidde r= 2th e Torpean c(ed b_etagble=0ixfnffnfinfg8 00a8td af9ra1m6e 000) x fffff80117753698 _kfree() at _kfree+0x593 0xffffffff80658413 _kfree() at _kfree+0x593 0xffffffff80658413 iconv_sysctl_add() at iconv_sysctl_add+0x172 0xffffffff82600c12 sysctl_root.isra.5() at sysctl_root.isra.5+0x166 0xffffffff80683d06 userland_sysctl() at userland_sysctl+0x111 0xffffffff806840a1 sys___sysctl() at sys___sysctl+0x74 0xffffffff80684204 Debugger("panic") CPU2 stopping CPUs: 0x0000003b stopped db> refcount=-2046 on a live handle means ~2047 lost/unmatched decrements landed on that chunk after reuse: the compounding write-into-freed- memory corruption that BADFREE2 then catches. (An analogous fourth session with the same objdir mistake produced the same panic signature with refcount=-2047; transcript only, not re-captured.)