Solaris Core dump analysis

Question

I use pstack to analyze core dump files in Solaris

How else can I analyze the core dump from solaris?

What commands can be used to do this?

What other information will be available from the dump?

Solution 1

You can use Solaris modular debugger,mdb, or dbx. mdb comes with SUNWmdb (or SUNWmdb x for the 64 bits version) package.

A core file is the image of your running process at the time it crashed.

Depending on whether your application was compiled with debug flags or not,you will be able to view an image of the stack, hence to know which function caused the core, to get the value of the parameters that were passed to that function, the value of the variables, the allocated memory zones ...

On recent solaris versions, you can configure what the core file will contain with the coreadm command ; for instance, you can have the mapped memory segments the process were attached to.

Refer to MDB documentation and dbx documentation. The GDB quick reference card is also helpful once you know the basics of GDB.

Solution 2

I guess any answer to this question should start with a simple recipe:

For dbx, the recipe is:

% dbx a.out core
(dbx) where
(dbx) threads
(dbx) thread t@3
(dbx) where

Solution 3

If the core dump is from a program you wrote or built, then use whichever debugger you would normally use to debug the running application. They should all be able to load core files. If you're not picky about debuggers, and you're using Solaris, I would recommend dbx. It will help to get the latest FCS version of Sun Studio with patches, or else the latest Express version of Sun Studio. It's also very helpful if you can load the core file into the debugger on the same system where the core file was created. If the code in the libraries is different from when the core file was created, then stack trace won't be useful when it goes through libraries. Debuggers also use OS helper libraries for understanding the libthread and runtime linker data structures, so IF you need to load the core file on a different machine, you'll want to make sure the helper libraries installed on the OS match the system data structures in the OS. You can find out everything you never wanted to know about these system libraries in a white paper that was written a few years ago.

http://developers.sun.com/solaris/articles/DebugLibraries/DebugLibraries_content.html

Solution 4

The pflags command is also useful for determining the state each thread was in when it core dumped. In this way you can often pinpoint the problem.

Solution 5

I would suggest trying gdb first as it's easier to learn basic tasks than the native Solaris debuggers in my opinion.

View more solutions

Comments

[hookenz]

The Solaris modular debugger is fantastic and when used with libumem is a very powerful tool. blogs.sun.com/pnayak/entry/finding_memory_leaks_within_solar‌​is

[PP.]

This blog helps you use mdb to analyse a coredump in Solaris: cuddletech.com/blog/pivot/entry.php?id=965

[Kaz]

Unfortunately, GDB 7.5 and up can't read Solaris core dumps any more. This is an unsolved problem sitting in Bugzilla since 2012.