GDB Quirks with Thread Process

Question

I am debugging a process with multiple threads in GDB. I compiled the sole source file with the -g flag. However, while running in GDB, the following scenario occurs:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7fe2b70 (LWP 2604)]
0x00000011 in ?? ()

Prior to the switch, the particular thread executes a sleep(5);

Why can't GDB identify the point from which the code "segfaulted"?

Answer 1

0x00000011 is not a valid address, especially not for code. This tells us, that there is no code (thus no function) at 0x00000011. And this tells us, that your stack is corrupted. Without a "working" stack, gdb is unable to figure out how your thread ended up where is has, because it does not log any calls by default and hence relies solely on the stack.

EDIT Note that on x86 you will end up with similar behavior as you've described by code like

_start:
   mov eax,0x11
   jmp eax

This leads to a jump/branch to a region (0x11) where there's no code and consequently no debugging symbols neither. This might happen in a case like in my example, but also if the stack is overridden (corrupted) and the returning jump leads to an invalid address (like 0x11)