How to get backtrace with gdb when it cannot determine size of stack frame?

Question

I have run into a core and cannot get the traceback from it. I have two questions.

1. Can I find out the line which causes the crash or where the crash occurred from the list command output?
2. How to deal with it otherwise. What should I set heuristic-fence-post to to get some meaningful data. I tried setting it to 0 but no luck.

(gdb) bt

0 0x00e67a24 in ?? ()

warning: GDB can't find the start of the function at 0xe67a24.

GDB is unable to find the start of the function at 0xe67a24

and thus can't determine the size of that function's stack frame. This means that GDB may be unable to access that stack frame, or the frames below it. This problem is most likely caused by an invalid program counter or stack pointer. However, if you think GDB should simply search farther back from 0xe67a24 for code which looks like the beginning of a function, you can increase the range of the search using the `set heuristic-fence-post' command. (gdb)

Answer 1

A workaround that often works when I see this problem is the command:

x/100a $sp

This will dump the stack with symbols and it's likely that at recent parts of the backtrace will be there. It still won't find the actual current stackframe, but should find the most recent ones with symbols.

Depending upon the target architecture, $sp may need to be something else - whatever register is the stack pointer.

The most common case for me to see gdb fail to find the call stack is for a crash in OpenGL drivers which do not use the expected ARM ABI calling conventions.

Answer 2

I ran into this same error and it turned out to be a symptom of a different problem: I didn't provide a file to gdb, which therefore couldn't build a symbol table. Starting it via gdb filename instead of just gdb fixed this as well.