Skip to main content

kalloc and kfree Trace Access

kalloc and kfree trace access are available via GDB/LLDB.

The kalloc tracer maintains a memory map of kernel virtual memory. Each entry is tagged not only with its size, but the stack backtrace of where the allocation happened, where the deallocation happened, and error state (for instance, double-free), as well as microsecond timestamps for allocation and deallocation events.

By running a VM with kalloc enabled, a new GDB monitor command `ka`` available to deal with allocations in the kernel.

# Display information about a given address or address range
ka <va>[-<va>] [<sz>[-<sz>]]

# Display information about a given address and its few neighbours
ka show <va>

# Display information about all blocks allocated by given PC range
ka alloc <pc>[-<pc>]

# Display information about all blocks freed by given PC range
ka free <pc>[-<pc>]

# Display information about suspected errors
ka error [<va>-<va>]

Here's an example of the output of ka show:

(gdb) mon ka show 0xffffffe3869c9600
A ffffffe3869c9180-ffffffe3869c92bf ( 140/ 140) alloc[fffffff02ae0a6a0 fffffff02ae0bcdc fffffff02ad8af30 fffffff02adb31f8 fffffff02adb30a8 fffffff02adb414c fffffff02ba130ac fffffff02ba127e4 fffffff02b9d91f8 fffffff02b9d70b4 fffffff02ad78650 fffffff02ad77bd8 fffffff02ad75e98]@2908919us
A ffffffe3869c9300-ffffffe3869c943f ( 140/ 140) alloc[fffffff02ae0a6a0 fffffff02ae0bcdc fffffff02ad8af30 fffffff02adb31f8 fffffff02adb30a8 fffffff02adb414c fffffff02b8e59cc fffffff02ad78650 fffffff02ad77bd8 fffffff02ad75e98 fffffff02ad7c664]@3360380us
A ffffffe3869c9480-ffffffe3869c95bf ( 140/ 140) alloc[fffffff02ae0a6a0 fffffff02ae0bcdc fffffff02ad8af30 fffffff02adb31f8 fffffff02adb30a8 fffffff02adb414c fffffff02b516654 fffffff02ad78650 fffffff02ad77bd8 fffffff02ad75e98 fffffff02ad7c664]@3341444us
> +0 A ffffffe3869c9600-ffffffe3869c971f ( 120/ 120) alloc[fffffff02a7dad00 fffffff02a7da740 fffffff02a7d54a8 fffffff02a8d5228 fffffff02a8ca578]@1551499us
A ffffffe3869c9780-ffffffe3869c98bf ( 140/ 140) alloc[fffffff02ae0a6a0 fffffff02ae0bcdc fffffff02ad8af30 fffffff02adb31f8 fffffff02adb30a8 fffffff02adb414c fffffff02b516654 fffffff02ad78650 fffffff02ad77bd8 fffffff02ad75e98 fffffff02ad7c664]@3341915us
A ffffffe3869c9900-ffffffe3869c9a3f ( 140/ 140) alloc[fffffff02ae0a6a0 fffffff02ae0bcdc fffffff02ad8af30 fffffff02adb31f8 fffffff02adb30a8 fffffff02adb414c fffffff02b516654 fffffff02ad78650 fffffff02ad77bd8 fffffff02ad75e98 fffffff02ad7c664]@3342956us
A ffffffe3869c9a80-ffffffe3869c9b8f ( 110/ 110) alloc[fffffff02ad27258 fffffff02ad2c948 fffffff02ad2e82c fffffff02ad3038c fffffff02ae98144 fffffff02ae980a0 fffffff02ae66b74 fffffff02a7d5c68]@1859199us

Here you can get information about neighboring kalloc blocks, who allocated them (i.e. backtrace), if they’ve been freed but not reused and who freed them. You can also query by PC range.

Running mon ka on a virtual device with kalloc enabled will give you a run down. This is another example to show all blocks kalloc’d by code with that address in backtrace:

(gdb) mon ka alloc 0xfffffff02b1a17e4
A ffffffdfa1d31400-ffffffdfa1d315ff ( 200/ 200) alloc[fffffff02bcfc740 fffffff02bcfc590 fffffff02c28cef4 fffffff02c294194 fffffff02ad6b864 fffffff02b1a17e4 fffffff02b1dca58 fffffff02b1b97c8 fffffff02b14d2b8 fffffff02ad78650 fffffff02ad77bd8]@4771164us
A ffffffe25410db70-ffffffe25410db6f ( 0/ 0) alloc[fffffff02bd03590 fffffff02bcfcea4 fffffff02bcfc8b4 fffffff02bcfc5ac fffffff02c28cef4 fffffff02c294194 fffffff02ad6b864 fffffff02b1a17e4 fffffff02b1dca58 fffffff02b1b97c8 fffffff02b14d2b8]@4771948us
A ffffffe25410e090-ffffffe25410e08f ( 0/ 0) alloc[fffffff02bd0379c fffffff02bcfcecc fffffff02bcfc8b4 fffffff02bcfc5ac fffffff02c28cef4 fffffff02c294194 fffffff02ad6b864 fffffff02b1a17e4 fffffff02b1dca58 fffffff02b1b97c8 fffffff02b14d2b8]@4773279us
A ffffffe386890940-ffffffe3868909ff ( c0/ c0) alloc[fffffff02bd035dc fffffff02bcfcea4 fffffff02bcfc8b4 fffffff02bcfc5ac fffffff02c28cef4 fffffff02c294194 fffffff02ad6b864 fffffff02b1a17e4 fffffff02b1dca58 fffffff02b1b97c8 fffffff02b14d2b8]@4771968us
A ffffffe386890ac0-ffffffe386890b7f ( c0/ c0) alloc[fffffff02bd035dc fffffff02bcfcea4 fffffff02bcfc8b4 fffffff02bcfc5ac fffffff02c28cef4 fffffff02c294194 fffffff02ad6b864 fffffff02b1a17e4 fffffff02b1dca58 fffffff02b1b97c8 fffffff02b14d2b8]@4771415us
A ffffffec155d8000-ffffffec15697fff (c0000/c0000) alloc[fffffff02bcfc70c fffffff02bcfc590 fffffff02c28cef4 fffffff02c294194 fffffff02ad6b864 fffffff02b1a17e4 fffffff02b1dca58 fffffff02b1b97c8 fffffff02b14d2b8 fffffff02ad78650 fffffff02ad77bd8]@4771145us