只有 gdb 在 ARM 上报告的回溯中的问号
我正在尝试在 ARM 上使用 gdbserver 调试软件以获取崩溃的回溯.不幸的是，我只得到问号.在任何地方，我都读到这个问题只是与缺少符号有关，但符号并没有从我的库中删除.
I'm trying to debug a software with gdbserver on ARM to get a backtrace of a crash. Unfortunately I get only question marks. Everywhere, I read this problem is simply related to the lack of symbols, but symbols are not stripped from my libraries.
如果我尝试使用 file 命令在客户端加载符号，我会得到:
If I try to use the file command to load the symbols in the client I get:
reading symbols from <path>/libQtWebKit.so.4.7.2...(no debugging symbols found)...done.
然后，当崩溃发生时:
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?)
我的库是在发布时编译的，但符号实际上在那里.使用 nm 我可以找到那些.为什么我只得到问号?这仅仅是因为库是用优化编译的吗?难道不能用release模式下的库调试吗?
My libraries are compiled in release but the symbols are actually there. With nm I can find those. Why do I only get question marks? Is this only because the libraries are compiled with optimization? Isn't it possible to debug with libraries in release mode?
推荐答案
corrupt stack 注释可能是你的问题.它看起来像一个返回地址或虚拟表条目或被零覆盖的东西，然后控制权转移到那里.即使您有可用的符号，这些地址也没有指向有效的符号.因此出现了段错误.
The corrupt stack note is probably your problem. It looks like a return address or virtual table entry or something was overwritten with zeros, and then control was transferred there. Even if you have symbols available, those addresses aren't pointing to valid symbols. Hence the segfault.
我不羡慕你的任务.这些是一些最难追踪的错误，甚至可以在您更改代码以尝试捕获它们时移动或暂时消失.你最好的选择通常是像 git bisect 或你的 VCS 等价物来找到引入它的提交.希望它不会太难复制.
I don't envy your task. These are some of the hardest bugs to track down, and can even move or temporarily go away when you make code changes to try and catch them. Your best bet is usually something like git bisect or your VCS equivalent to find the commit that introduced it. Hopefully it isn't too difficult to reproduce.
相关文章