how to examine core file

[federico_3]

I would like to check a core file : how to do this using adb ?


Federico

[Alex Glennie]

How can I determine what caused a programmatic core dump?

Solution

If you see a file named "core" lying around and don't know what program
left it there, try the `file' command:

$ file core

This should tell you the program that left the core file. For example:

$ file core
core: core file from 'audio_editor' - received SIGABRT

If by "programmatic core dump" you mean "my program dumped core", you can use
a good debugger and the sources to get the most thorough answer. Ask the
debugger for a stack trace, which will give you an idea of the routine that
the program was executing when it died.

You can also ask `adb' for a stack trace. To debug an errant program named
`a.out', run adb on a.out and core. Give adb two commands, $C (stack trace)
and $Q (quit). The adb program has no prompt, by the way.

$ PATH=$PATH:/usr/ccs/bin # to get to adb

$ a.out 4 5 6
Floating exception(coredump)

$ adb a.out core
$C
$$divI() from func+1C
func(0) from main+18
data address not found
$Q

The output above shows that when it dumped core, the program was executing a
function named $$divI(), which was called from func(), which was called from
main(). The argument passed to func() was zero. Someone who knows the
sources to the program may be able to interpret the meaning of the argument
or the order of program execution.

This use of adb is documented in the book "The Unix Programming Environment"
by Brian Kernighan and Rob Pike (1984, Prentice-Hall), available in technical
bookstores. Section 6.6, "On bugs and debugging", starting on page 187, is
especially valuable.

If by "programmatic core dump" you mean "caused by a deliberate programming
call that aborted the program", the errant program probably used the assert()
macro. In this case you would see a message indicating the source line on
which an assertion failed before the program dumps. For more information on
this, see the manual page assert(3X). To turn off assertion-checking,
recompile the program with -DNDEBUG.

[Guy Draper]

An easy way I have found is to run strings against the core file. I can usually get enough info to find out what the problem is.

[John Donovan_2]

Expanding on Guy's answer, at command prompt: strings core | more
The core file will probably be quite long. Instead of piping to more, you may wish to redirect to a separate file: strings core > mycore.txt

There will still be some unreadable characters, but you should be able to see familiar commands.

[Rick Beldin]

A strings on core is likely to yield nothing more than a list of all the strings that the binary had. This would include error messages that are compiled in, strings used internally in the program and the like. This is not likely to aid in the resolution of the problem and I never ask a customer for it.

With application built on HP-UX, I ask for the following:

1. Determine what program cored

file core

2. Determine what libraries the program uses

chatr

3. Versions of libraries in core

what core

4. Stack trace

Three main options (in order of my
preference)
a. gdb core
(gdb) bt
b. dde -ui line core
dde> tb
c. adb


gdb is free to HP customers. Look on
software.hp.com for it. It installs
in /opt/langtools/bin/

[Emer Bonham_1]

I am trying to get a stack trace form a core file which dumped using java, but I get the following warning;
>gdb java core
Core was generated by `java'.
Program terminated with signal 6, Aborted.

warning: The shared libraries were not privately mapped; setting a
breakpoint in a shared library will not work until you rerun the program.

Error while reading dynamic library list.

#0 0xc01f2740 in ?? ()

Does anyone know how I can get around this?

thanks, Emer