Getting Started: Creating a Sample Crash Dump
This section shows you how to obtain a sample crash dump, and
how to invoke MDB in order to examine it.
The kernel memory allocator contains many advanced debugging features, but these are not enabled
by default because they can cause performance degradation. In order to follow the
examples in this guide, you should turn on these features. You should enable
these features only on a test system, as they can cause performance degradation
or expose latent problems.
The allocator's debugging functionality is controlled by the kmem_flags tunable. To get
started, make sure kmem_flags is set properly:
# mdb -k
If kmem_flags is not set to 'f', you should add the line:
to /etc/system and reboot the system. When the system reboots, confirm that kmem_flags
is set to 'f'. Remember to remove your /etc/system modifications before returning this system
to production use.
Forcing a Crash Dump
The next step is to make sure crash dumps are properly configured. First,
confirm that dumpadm is configured to save kernel crash dumps and that savecore is
enabled. See dumpadm(1M) for more information on crash dump parameters.
Dump content: kernel pages
Dump device: /dev/dsk/c0t0d0s1 (swap)
Savecore directory: /var/crash/testsystem
Savecore enabled: yes
Next, reboot the system using the -d flag to reboot(1M), which forces the
kernel to panic and save a crash dump.
# reboot -d
Sep 28 17:51:18 testsystem reboot: rebooted by root
panic[cpu0]/thread=70aacde0: forced crash dump initiated at user request
401fbb10 genunix:uadmin+55c (1, 1, 0, 6d700000, 5, 0)
%l0-7: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
When the system reboots, make sure the crash dump succeeded:
$ cd /var/crash/testsystem
bounds unix.0 unix.1 vmcore.0 vmcore.1
If the dump is missing from your dump directory, it could be that
the partition is out of space. You can free up space and
run savecore(1M) manually as root to subsequently save the dump. If your dump
directory contains multiple crash dumps, the one you just created will be the
unix.[n] and vmcore.[n] pair with the most recent modification time.
Now, run mdb on the crash dump you created, and check its status:
$ mdb unix.1 vmcore.1
Loading modules: [ unix krtld genunix ip nfs ipc ]
debugging crash dump vmcore.1 (32-bit) from testsystem
operating system: 5.10 Generic (sun4u)
panic message: forced crash dump initiated at user request
In the examples presented in this guide, a crash dump from a
32-bit kernel is used. All of the techniques presented here are applicable
to a 64-bit kernel, and care has been taken to distinguish pointers (sized
differently on 32- and 64-bit systems) from fixed-sized quantities, which are invariant with respect
to the kernel data model.
An UltraSPARC workstation was used to generate the example presented. Your results can
vary depending on the architecture and model of system you use.