For lack of a better place, here are some unorganized kernel debugging tips.
The GDB scripts I use are at https://github.com/bsdjhb/kdbg/ in the 'gdb' subdirectory.
Finding the range of corrupted data for a UMA use after a free panic
Finding the relative offset of the corruption:
(gdb) p (char *)p - mem $1 = 17382 (gdb) find /w p, p+cnt, 0xdeadc0de 0xfffffe0149627790 .... (gdb) p (char *)0xfffffe0149627790 - (char *)p $2 = 17352
In this case, the corrupted data was 17382 bytes long at an offset of 17382 within memory region.
Making use of MALLOC_DEBUG_MAXZONE from gdb
With this option enabled, one can get a list of the malloc types that hash to the zone experiencing the use after free:
(gdb) malloc_zone_index zone malloc-32: index 1 (gdb) malloc_zone_matches 1 epair netgraph_sock netgraph_path netgraph_item ...
On successive runs, modify 'debug.malloc.zone_offset' to force different hashes and then use comm(1) or something similar to find the overlap between the malloc zones that match on each run.
Examining the most recent crash on a box
% kgdb -n last
Examining a crash from another box where the kernel isn't in /boot
This assumes the kernel and debug symbols are in the same relative sysroot, e.g. /tmp/foo/boot/kernel and symbols in /tmp/foo/usr/lib/debug/boot/kernel:
% gdb -iex "set sysroot /tmp/foo" /tmp/foo/boot/kernel/kernel (gdb) target vmcore /path/to/vmcore