tags:

views:

444

answers:

3

I'm trying to use gdb in postmortem mode with the core dump of a crashed process. I can get a stack trace, but instead of showing me the actual location in the offending function, gdb shows me the line number of a two-line inlined function that the offending function calls.

The inlined function is called many, many places; how do I find which call triggered the crash? How do I find the code immediately around the inlined function?

A: 

You can try setting OPTIMIZE to NO (eg. setenv OPTIMIZE NO) and rebuild the project: this tells compiler not optimize code, hence it may not inline function calls.

Thanks, but I'd really like to be able to do postmortems of optimized (release) builds so that we can analyze core dumps from customers.
Josh Kelley
+2  A: 

I assume that the "many many calls to the inlined function" are all happening from within a single "offending function" (otherwise your question doesn't make sense to me).

Your best bet is to note the IP address of the crash point in GDB, then use "objdump -dS ./a.out" and find that IP in the output.

Employed Russian
+1  A: 

Go to the stack frame in question, print the instruction point (e.g. p $rip), then use it to look it up manually with e.g. "addr2line -e -i 0x84564756".

This doesn't scale, but at least it works.

Rupert