Summary

• Some common problems are likely to occur in the kernel, such as deadlocks and invalid memory accesses, which in turn can cause a kernel panic.
• A kernel panic is a defense mechanism against exceptional or erroneous conditions the kernel cannot recover from. It basically disables the system in order to prevent corruption of the file system or other file storage.
• Mac OS X provides a wide range of useful debugging mechanisms out of the box, ranging from a simple tracing and logging mechanism to the built-in support for remote kernel debugging.
• Mac OS X can be configured using the kdumpd to accept a core dump from a remote system when it crashes (or if triggered manually). The core dump consists of active/wired memory and can be loaded into GDB.
• The kernel can be debugged from a remote system over FireWire and Ethernet. This mechanism is built in, but not activated by default. Remote debugging can be enabled by setting the appropriate NVRAM parameters and flags.
• Apple usually provides a Kernel Debug Kit for each released build of Mac OS X. The kit contains scripts, a debug version of the kernel, and I/O Kit family KEXTs. The debug kit also contains macros for simplifying kernel debugging in GDB. The macros allow you to get information about call stacks and examine the kernel’s key data structures. The kernel can also be live debugged with GDB while running from the same machine.
• To debug your own KEXT, you have to generate debugging symbols for it. Because a KEXT is dynamically loaded in the kernel, we need to generate the correct symbol addresses for a KEXT. The Kernel Debug Kit provides the createsymbolfiles script to help with this.
• A kernel panic log contains a lot of useful information we can use to backtrack and find the location that caused the crash.
• The ioclasscount tool tracks instance counts of classes in I/O Kit and can be used to detect memory leaks or other problems.