Question

What are the ‘best practices’ when it comes to debugging core dumps using GDB?

Currently, I am facing a problem:

• The release version of my application is compiled without the ‘-g’ compiler flag.
• The debug version of my application (compiled with ‘-g’) is archived (along with the source code, and a copy of the release binary).

Recently, when a user gave me a core dump, I tried debugging it using

gdb --core=./core.pid ./my_app_debug-bin

The core was created by my_app_release-bin. There seems to be some kind of mismatch between the core file and the binary.

On the other hand, if I try

gdb --core=./core.pid ./my_app_release-bin

the core matches but I am unable to get source code line numbers (although I get the function names).

Is this what is practised? Because I feel I am missing something here.

Answer 1

It sounds like there are other differences between your release and debug build then simply the absence/presence of the -g flag. Assuming that’s the case, there is nothing you can do right now, but you can adjust your build to handle this better:

Here’s what we do at my place of work.

1. Include the -g flag when building the release version.
2. Archive that version.
3. run strip --strip-unneeded on the binary before shipping it to customers.

Now, when we get a crash we can use the archived version with symbols to do debugging.

One thing to note is that if your release version includes optimization, debugging may be difficult even with symbols. For example, the optimizer can reorder your code so even though the debugger will say you crashed on line N, you can’t assume that the code actually executed line N-1.