c++ - 如何追踪 SIGFPE/算术异常

Question

我有一个针对 Linux 交叉编译的 C++ 应用程序，该应用程序在 ARM CortexA9 处理器上运行，该处理器因 SIGFPE/算术异常而崩溃。最初我认为这是因为 gcc 的 -O3 标志引入了一些优化，但后来我在 Debug模式下构建它，它仍然崩溃。

我用 gdb 调试了应用程序，它捕获了异常，但不幸的是，触发异常的操作似乎也破坏了堆栈，所以我无法获得有关代码中导致这种情况发生的位置的任何详细信息。我最终能得到的唯一细节是触发异常的操作(来自以下堆栈跟踪):

    3 raise()  0x402720ac   
    2 __aeabi_uldivmod()  0x400bb0b8    
    1 __divsi3()  0x400b9880

__aeabi_uldivmod() 正在执行 unsigned long long 除法和提醒，所以我尝试了蛮力方法并在我的代码中搜索了可能使用该操作但没有成功的地方，事实证明一项艰巨的任务。我还尝试检查是否有可能被零除，但代码库又非常大，检查每个除法操作是一种麻烦且有点愚蠢的方法。因此，必须有一种更聪明的方法来弄清楚发生了什么。

当调试器无能为力时，是否有任何技术可以追踪此类异常的原因？

更新: 在处理十六进制数、转储内存和进行堆栈取证(感谢 Crashworks)之后，我在 ARM 编译器文档中遇到了这个 gem(即使我没有使用 ARM Ltd.编译器):

Integer division-by-zero errors can be trapped and identified by re-implementing the appropriate C library helper functions. The default behavior when division by zero occurs is that when the signal function is used, or __rt_raise() or __aeabi_idiv0() are re-implemented, __aeabi_idiv0() is called. Otherwise, the division function returns zero. __aeabi_idiv0() raises SIGFPE with an additional argument, DIVBYZERO.

所以我在 __aeabi_idiv0(_aeabi_ldiv0) 等处设置了一个断点，瞧!我在被完全破坏之前得到了完整的堆栈跟踪。感谢大家提供非常翔实的答案!

免责声明:“获胜”答案是完全主观地选择的，考虑了它的建议在我的调试工作中的重要性，因为不止一个提供了信息并且真正有用。

Answer 1

我的第一个建议是打开一个内存窗口，查看堆栈指针周围的区域，然后深入挖掘它，看看是否可以在附近找到未损坏的堆栈帧，这可能会为您提供有关崩溃位置的线索。通常 stack-trashes 只会烧掉几个堆栈帧，所以如果你向上看几百个字节，你可以越过损坏的区域并大致了解代码的位置。您甚至可以向下查看堆栈，假设死函数可能在它死之前调用了一些其他函数，因此内存中可能仍然有一个指向当前 IP 的旧帧。

在评论中，我链接了一些演示幻灯片，这些幻灯片说明了 PowerPC 上的技术——请查看 #73-86 附近的一个类似的错误堆栈崩溃的案例研究。显然，您的 ARM 堆栈帧的布局会有所不同，但一般原则是成立的。