⬢ DragonFlyBSD Kernel Audit
DF-5765 / panic.txt
← back to finding ↓ download raw
DF-5765 — panic captured on serial console (run 1 of the race rig)

login: [xlatrace] harness loaded: production iconv.c + iconv_xlat.c compiled in verbatim
[xlatrace] racer on cpu2 up (zz9to:zz9from)
[xlatrace] 5 racers started
[xlatrace] racer on cpu4 up (zz9to:zz9from)
[xlatrace] racer on cpu1 done
[xlatrace] racer on cpu4 done
[xlatrace] racer on cpu5 done
[xlatrace] racer on cpu3 done
[xlatrace] racer on cpu3 up (zz9to:zz9from)
panic: BADFREE2
cpuid = 2
Trace beginning at frame 0xfffff801184df698
[xlatrace] rac_ekrf roene (c)p ua4t  up (_zkzf9rteoe:+z0zx95f9r3o m0)xfffffff80658413
_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
Stopped at      Debugger+0x7c:  movb    $0,0xbdaf09(%rip)
db>

Notes:
- The garbled line interleaved into the panic trace is a racer kprintf
  ("[xlatrace] racer on cpu4 up (zz9to:zz9from)") being corrupted by the
  panic-time console interleave -- evidence the racer threads were active
  on other CPUs at panic time.
- BADFREE2 = production kfree() sanity check: the chunk being freed by
  the production iconv_sysctl_add error path was already free / had a
  corrupted free-list linkage. The racer's unlocked cp_refcount-- (a
  write into freed cspair memory from production iconv_xlat_close) /
  cp_refcount++ (iconv_xlat_open into a freed+reused chunk) corrupted
  the allocator's freelist.
- Kernel: DragonFly 6.5-DEVELOPMENT #0 X86_64_GENERIC (2026-07-02).