Only backtrace question marks reported by gdb on ARM

Question

I am trying to debug software using gdbserver on ARM to get the backtrack of the crash. Unfortunately, I only get question marks. Everywhere, I read this problem, simply due to the lack of characters, but the characters are not deleted from my libraries.

If I try to use the file command to load characters in the client, I get:

reading symbols from <path>/libQtWebKit.so.4.7.2...(no debugging symbols found)...done. 

and then when the failure occurs:

 Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x4bf38b88 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) 

My libraries are compiled in version, but the characters are actually there. With nm, I can find them. Why do I get only question marks? Is it just because libraries are compiled with optimizations? Is it impossible to debug libraries in release mode?

Answer 1

A corrupt stack note is probably your problem. This is like a return address or a virtual table entry, or something was overwritten with zeros, and then control was passed there. Even if you have characters, these addresses do not indicate valid characters. Hence, segfault.

I do not envy your task. These are some of the most difficult bugs to track and may even move or temporarily go away when you make code changes to try and catch them. Best of all, usually something like git bisect or your VCS equivalent, to find the command that introduced it. I hope this is not so difficult to reproduce.

Answer 2

One trick you can sometimes use when the “SEGV at address 0” problem is to manually pull the return address from the top of the stack to the computer and try to trace the stack. This assumes that you got address 0 by making an indirect call using the NULL pointer, which is the most common way to access 0.

Now I'm not too familiar with ARM, but on an x86 PC you would do:

 (gdb) set $eip = *(void **)$esp (gdb) set $esp = $esp + 4 

and then follow another return line to find out where you really are.

If you can define the calling convention used for ARM by your compiler, you should do something like this.