带有线程过程的GDB怪癖 [英] GDB Quirks with Thread Process

问题描述

我正在调试GDB中有多个线程的进程。我使用 -g 标志编译了唯一的源文件。但是，在GDB中运行时，会出现以下情况：

 编程接收到的信号SIGSEGV，分段错误。 
 [切换到线程0xb7fe2b70（LWP 2604）] 
 0x00000011 in ?? （）
  

在切换之前，特定线程执行 sleep（5 ）;

为什么GDB无法识别代码为segfaulted的点？

0x00000011不是有效的地址，尤其不适用于代码。这告诉我们，在0x00000011没有代码（因此没有函数）。这告诉我们，你的堆栈已损坏。
没有一个工作堆栈，gdb无法弄清楚你的线程是如何结束的，因为默认情况下它不会记录任何调用，因此完全依赖于堆栈。

编辑
请注意，在x86上，您最终会遇到类似的行为，正如您通过代码描述的那样：

  _start：
 mov eax，0x11 
 jmp eax 
  

这会导致跳转/跳转到一个区域（0x11），因为没有代码，因此也没有调试符号。这可能发生在像我的例子那样的情况下，但是如果堆栈被覆盖（损坏）并且返回的跳转导致无效的地址（如0x11）。

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"?

解决方案

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)

这篇关于带有线程过程的GDB怪癖的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！