analysis of core file

Question

hi

I'm using Linux redhat 3, can someone explain how is that possible that i am able to analyze with gdb , a core dump generated in Linux redhat 5 ?

not that i complaint :) but i need to be sure this will always work... ?

EDIT: the shared libraries are the same version, so no worries about that, they are placed in a shaerd storage so it can be accessed from both linux 5 and linux 3.

thanks.

Answer 1

You have asked similar question and accepted an answer, ofcourse by yourself here : http://stackoverflow.com/questions/3502340/analyzing-core-file-of-shared-object

Once you load the core file you can get the stack trace and get the last function call and check the code for the reason of crash.

There is a small tutorial here to get started with.

EDIT:

Assuming you want to know how to analyse core file using gdb on linux as your question is little unclear.

Answer 2

You can always run gdb -c /path/to/corefile /path/to/program_that_crashed. However, if program_that_crashed has no debug infos (i.e. was not compiled and linked with the -g gcc/ld flag) the coredump is not that useful unless you're a hard-core debugging expert ;-)

Note that the generation of corefiles can be disabled (and it's very likely that it is disabled by default on most distros). See man ulimit. Call ulimit -c to see the limit of core files, "0" means disabled. Try ulimit -c unlimited in this case. If a size limit is imposed the coredump will not exceed the limit size, thus maybe cutting off valuable information.

Also, the path where a coredump is generated depends on /proc/sys/kernel/core_pattern. Use cat /proc/sys/kernel/core_pattern to query the current pattern. It's actually a path, and if it doesn't start with / then the file will be generated in the current working directory of the process. And if cat /proc/sys/kernel/core_uses_pid returns "1" then the coredump will have the file PID of the crashed process as file extension. You can also set both value, e.g. echo -n /tmp/core > /proc/sys/kernel/core_pattern will force all coredumps to be generated in /tmp.

Answer 3

I understand the question as:

how is it possible that I am able to analyse a core that was produced under one version of an OS under another version of that OS?

Just because you are lucky (even that is questionable). There are a lot of things that can go wrong by trying to do so:

• the tool chains gcc, gdb etc will be of different versions
• the shared libraries will be of different versions

so no, you shouldn't rely on that.

Answer 4

In my experience analysing core file, generated on other system, do not work, because standard library (and other libraries your program probably use) typically will be different, so addresses of the functions are different, so you cannot even get a sensible backtrace.

Don't do it, because even if it works sometimes, you cannot rely on it.

Answer 5

You can try following commands of GDB to open a core file

gdb
 (gdb) exec-file <executable address>
 (gdb) set solib-absolute-prefix <path to shared library>
 (gdb) core-file <path to core file>

The reason why you can't rely on it is because every process used libc or system shared library,which will definitely has changes from Red hat 3 to red hat 5.So all the instruction address and number of instruction in native function will be diff,and there where debugger gets goofed up,and possibly can show you wrong data to analyze. So its always good to analyze the core on the same platform or if you can copy all the required shared library to other machine and set the path through set solib-absolute-prefix.