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:

<code>
(gdb) p (char *)p - mem
$1 = 17382
(gdb) find /w p, p+cnt, 0xdeadc0de
0xfffffe0149627790
....
(gdb) p (char *)0xfffffe0149627790 - (char *)p
$2 = 17352
</code>

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:

<code>
(gdb) malloc_zone_index zone
malloc-32: index 1
(gdb) malloc_zone_matches 1
epair
netgraph_sock
netgraph_path
netgraph_item
...
</code>

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 ===

<code>
% kgdb -n last
</code>

=== 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:

<code>
% gdb -iex "set sysroot /tmp/foo" /tmp/foo/boot/kernel/kernel
(gdb) target vmcore /path/to/vmcore
</code>