Go to main content

Troubleshooting System Administration Issues in Oracle® Solaris 11.4

Exit Print View

Updated: November 2020
 
 

Examining Crash Dump Information

You can examine the control structures, active tables, memory images of a live or crashed system kernel, and other information about the operation of the kernel by using the mdb utility.


Note -  This procedure provides only a limited example of how to use the mdb utility. Using the mdb utility to its full potential requires a detailed knowledge of the kernel, and, is beyond the scope of this guide. For further information about using this utility, see the Oracle Solaris Modular Debugger Guide and mdb(1) man page.

How to Examine Crash Dump Information

  1. Become an administrator.

    See Using Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.4.

  2. Change to the directory where the crash dump information has been saved.

    For example, to change to the default directory:

    $ cd /var/crash

    If you are unsure of the location of the crash dump, use the dumpadm command to determine where the system has been configured to store kernel crash dump files. The following sample output shows that the default directory location has not been changed:

    $ /usr/sbin/dumpadm
          Dump content: kernel with ZFS metadata
           Dump device: /dev/zvol/dsk/rpool/dump (dedicated)
    Savecore directory: /var/crash
      Savecore enabled: yes
       Save compressed: on
  3. Examine the crash dump by using the modular debugger utility (mdb).
    $ /usr/bin/mdb crashdump-file

    For example:

    $ /usr/bin/mdb vmcore.0

    The command can also be specified as follows:

    $ /usr/bin/mdb 0
  4. Display the system crash status.
    > ::status
       .
       .
       .
    > ::system
       .
       .
       .

    The ::system dcmd command is available only when you examine a kernel crash dump or a live system.

  5. Quit the mdb utility.

    Use one of the following commands at the > prompt:

    • ::quit
    • $q
Example 4  Examining Crash Dump Information

This example shows sample output from the mdb utility, which includes system information and identifies the tunables that are set in the /etc/system file of the system.

# cd /var/crash/5
# mdb 5
Loading modules: [ unix genunix specfs dtrace zfs kcf rpcmod scsi_vhci ldc
mac
ip hook neti ds sockfs arp idm sas cpc fctl fcip ptm ufs nfs ]
vmcore.5> ::status
debugging crash dump vmcore.5 (64-bit, DEBUG) from server1.example.com
operating system: 5.11 11.4.21.66.0 (sun4v) [internal version: on-gate]
usr/src version: 46827:c6c498dccaf4:st_067+13
usr/closed version: 2799:6c2118dd1009:st_067+1
image uuid: 924041e9-8695-4ea3-80c5-e00ea4c9ddc2
dump uuid:  924041e9-8695-4ea3-80c5-e00ea4c9ddc2
panic message: victim thread timed out entering the same lock
dump crash time: 2020 Mar 10 09:26:49
complete: yes, all pages present as configured
dump content: kernel [LOADED,UNVERIFIED] (core kernel pages)
              zfs [LOADED,UNVERIFIED] (ZFS metadata (ZIO buffers))
panicking PID: 1 (not dumped)
deferred dump not attempted
WARNING: /etc/system was modified. Use ::system for details.
vmcore.5> ::system
set secext_kadi_status=0x0 [0t0]
set secext_rsbs_status=0x0 [0t0]
vmcore.5> ::quit