我用gdb调试了应用程序,捕获异常,但不幸的是,操作触发异常似乎也会垃圾堆栈,所以我无法获得任何关于我的代码中导致发生的地方的详细信息.我可以得到的唯一的细节是触发异常的操作(从以下堆栈跟踪)：

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

__aeabi_uldivmod()正在执行一个无符号的长时间划分和提醒,所以我尝试了强力的方法,并搜索我的代码可能使用该操作的地方,但没有太多的成功,因为它被证明是一个艰巨的任务.此外,我还试图检查潜在的部门为零,但代码基础却相当大,并检查每个部门的操作,这是一个麻烦和有点愚蠢的方法.所以必须有一个更聪明的方式来弄清楚发生了什么.

当调试器无法做很多帮助时,是否有任何技巧来追踪这种异常的原因？

更新：对十六进制数进行处理后,转储内存并进行堆栈取证(谢谢Crashworks)我在ARM编译器文档中遇到了这个gem(即使我没有使用ARM的编译器)：

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)et Voila !,我完整的堆栈跟踪完全被丢弃.感谢大家的非常翔实的答案！

免责声明：“获奖”答案是单独和主观地考虑到我的调查工作的建议的重量,因为多个信息丰富,真正有用.