For lack of a better place, here are some unorganized kernel debugging tips.

The GDB scripts I use are at 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
(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

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

JohnBaldwin/KernelDebugTips (last edited 2022-02-11T16:25:43+0000 by JohnBaldwin)