ansaurus

Question

Answer 1

A:

No, you don't miss anything. debug and release are just different binaries, so the core files of release don't match the debug binary. You have to look at machine code to get something from the release core dump.

You probably have to ask your user how the crash happened and collect additional log information or whatever you app produces.

2010-02-15 08:00:43

Hey nodan,I already log quite a lot of information in the application, but sometimes it may not be quite enough. Users most often don't know what caused the crash because it runs as a background process. I also have some more information on a 'addr2line' tool. I think I'll give that one a try too.

themoondothshine 2010-02-15 08:42:18

Answer 2

+6 A:

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.

Include the -g flag when building the release version.
Archive that version.
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.

R Samuel Klatchko 2010-02-15 08:06:37

Hey Samuel,This is the right way to go, I think. Even @Michael pointed to a similar solution.However, the debug/release binaries only have the difference of -g. There's also the macros _DEBUG (for debug) and NDEBUG (for release). Maybe that is causing the issue?Anyway, I plan to explore stripped binaries a little more.Thanks!

themoondothshine 2010-02-15 08:35:07

BTW, do you know anything about an 'addr2line' tool? I found obscure references to it. It is supposed to be able to convert addresses to line numbers given the source code. I already have the function addresses, all I need is a mapping to source code...

themoondothshine 2010-02-15 08:44:27

@themoondothshine: GDB can do this for you (so long as it has debug symbols), use `info line *0xsomeaddr`

Hasturkun 2010-02-15 09:41:01

Thanks @Hasturkun. The addr2line is actually used to convert the output of the 'backtrace' system call. Anyway, I tried most of the techniques in the answers here, and this is working out best: -- Compile using "-g" flag -- Copy debug symbols using 'objcopy --only-keep-debug MyApp-bin MyApp-bin.debug' -- Strip debug symbols using 'strip -g MyApp-bin' -- Add a debug link using 'objcopy --add-gnu-debuglink=MyApp-bin.debug MyApp-bin'

themoondothshine 2010-02-15 10:14:29

@themoondoshine - if _DEBUG or NDEBUG have different values between your release and debug version that can make the difference (if you have any conditional compilation based on those flags, either direct or indirect though something like `assert`, then changing them will affect the binary).

R Samuel Klatchko 2010-02-15 16:32:31

Answer 3

+3 A:

You need to do some additional stuff to create binaries with stripped debug information that you can then debug from cores. Best description I could find is here

Michael Anderson 2010-02-15 08:08:00

Hey Michael,Thanks for the link. It was really helpful.

themoondothshine 2010-02-15 08:30:20

ansaurus

tags:

views:

answers:

Debugging in Linux using core dumps

related questions