Core dump not in sync with gdb stack trace.

Question

I have a program which crashes due to a segmentation fault. The core file is produced.

running the core in gdb gives me the following:

HP gdb 6.1 for HP Itanium (32 or 64 bit) and target HP-UX 11iv2 and 11iv3.

Core was generated by `gcpf1fwcApp'.
Program terminated with signal 6, Aborted.

I used the command

thread apply all bt

When I check the stack trace I get error in the main thread which is in waiting state.

However when I run the same program in GDB I get a completely different error in stack trace. Which seems more correct than the core dump.

The program has 31 threads.

Why do I get this kind of difference?

Answer 1

It is possible that you are simply looking at the wrong thread.

Try thread apply all where, and see if one of the threads is in fact abort()ing.

When debugging a live process, GDB will stop when a thread receives SIGABRT, and so will likely show you the relevant thread.

When debugging a core (post-mortem), GDB doesn't know which thread is relevant, and so shows them to you in whichever order the OS saved them into the core. Linux kernels save the thread which caused the process to die first, so GDB on Linux shows relevant thread from core. I am guessing that HP-UX does not do that, and so GDB shows you a "random" thread instead.