GDB损坏的堆栈框架-如何调试？

我有以下堆栈跟踪。可以从中得出一些有用的调试信息吗？

Program received signal SIGSEGV, Segmentation fault.
0x00000002 in ?? ()
(gdb) bt
#0  0x00000002 in ?? ()
#1  0x00000001 in ?? ()
#2  0xbffff284 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) 

当获得时，从哪里开始看代码Segmentation fault，而堆栈跟踪不是那么有用？

注意：如果我发布代码，则SO专家会给我答案。我想从SO那里获得指导，自己找到答案，所以我不在这里发布代码。道歉。

这些伪造的地址（0x00000002等）实际上是PC值，而不是SP值。现在，当您获得带有伪造的（非常小的）PC地址的SEGV时，有99％的时间是由于通过伪造的函数指针进行调用。请注意，C ++中的虚拟调用是通过函数指针实现的，因此虚拟调用的任何问题都可以以相同的方式体现出来。

间接调用指令只是推动PC呼叫到堆栈后，然后设置PC的目标值（在这种情况下假的），因此，如果这是发生了什么事，你可以很容易地通过手动弹出的PC从堆栈撤消。在32位x86代码中，您只需执行以下操作：

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

使用64位x86代码，您需要

(gdb) set $pc = *(void **)$rsp
(gdb) set $rsp = $rsp + 8

然后，您应该能够进行操作bt并弄清楚代码的实际位置。

其他1％的时间，错误将是由于覆盖堆栈而导致的，通常是通过使堆栈中存储的数组溢出来实现的。在这种情况下，您可以使用valgrind之类的工具来更清楚地了解情况

如果情况很简单，克里斯·多德（Chris Dodd）的答案就是最好的答案。看起来确实像是跳过了NULL指针。

但是，程序有可能在崩溃前用自己的脚，膝盖，脖子和眼睛开枪—覆盖堆栈，弄乱了帧指针和其他弊端。如果是这样，那么拆开哈希表就不太可能显示土豆和肉。

更有效的解决方案是在调试器下运行程序，并逐步执行功能，直到程序崩溃为止。一旦识别出崩溃的功能，请重新启动并进入该功能，并确定调用哪个功能会导致崩溃。重复直到找到唯一令人反感的代码行。75％的时间，修复将显而易见。

在其他25％的情况下，所谓的冒犯性代码是一条红色鲱鱼。它将对之前很多行（可能之前几千行）设置的（无效）条件做出反应。在这种情况下，选择的最佳课程取决于许多因素：主要是您对代码的了解和使用经验：

• 也许printf在关键变量上设置调试器观察点或插入诊断将导致必要的操作！
• 也许使用不同的输入来更改测试条件将比调试提供更多的见解。
• 也许第二双眼睛会迫使您检查您的假设或收集被忽视的证据。
• 有时，所需要做的只是吃晚饭并考虑收集的证据。

祝好运！

假设堆栈指针有效...

从回溯可能无法确切知道SEGV发生在哪里-我认为前两个堆栈帧已被完全覆盖。0xbffff284似乎是有效地址，但接下来的两个不是。要仔细查看堆栈，可以尝试以下操作：

gdb $ x / 32ga $ rsp

或变体（用另一个数字替换32）。从巨型（g）大小的堆栈指针开始，将打印出一定数量的单词（32），其格式为地址（a）。输入“帮助x”以获取有关格式的更多信息。

在这种情况下，使用一些标记为'printf'的代码来检测代码可能不是一个坏主意。

查看其他一些寄存器，看其中是否有一个缓存在其中的堆栈指针。从那里，您也许可以检索堆栈。同样，如果是嵌入式的，则通常在非常特定的地址处定义堆栈。使用它，有时还可以得到不错的堆栈。所有这些都假定当您跳到超空间时，您的程序并不会在整个过程中都在内存中呕吐...

如果是堆栈覆​​盖，则这些值很可能对应于程序中可识别的值。

例如，我只是发现自己正在查看堆栈

(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x000000000000342d in ?? ()
#2  0x0000000000000000 in ?? ()

并且0x342d是13357，当我为它添加应用程序日志时，结果是一个节点ID。这立即帮助缩小了可能发生堆栈覆盖的候选站点的范围。