3

所以当 glibc 崩溃时,它有一个*glibc detected * crash 消息。然后它会打印一堆回溯,比如

*** glibc detected *** ./odin: free(): invalid pointer: 0xbfba4444 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(+0x6b161)[0xb75f9161]
/lib/tls/i686/cmov/libc.so.6(+0x6c9b8)[0xb75fa9b8]
/lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0xb75fda9d]
/usr/lib/libstdc++.so.6(_ZdlPv+0x1f)[0xb77da2ef]

一切都很好,但是当事情崩溃的其他情况下,我一直在做 backtrace() 然后使用系统调用 addr2line 并打印函数中的实际点。但是当它是 glibc 崩溃时,它会退出绕过我调用的任何信号处理程序。

有没有办法解决这些 glibc 崩溃?

4

2 回答 2

3

IIRC,glibc 实际上调用abort(),因此处理SIGABRT和打印回溯应该可以为您提供所需的信息。

但是,我建议尝试 valgrind:您收到的消息表明您有内存损坏问题。

旁注(对不起,如果这是多余的;-)):核心转储有时比回溯更有用。它们可以通过例如ulimit -c unlimited在 bash 中设置来启用。当程序崩溃时,它会生成一个名为的文件core.(或者只是- 这取决于您正在运行的系统;如果您的系统运行 abrtd 核心文件,如果我没记错的话core,会放入其中)。/var/cache/abrt然后您可以通过运行使用 gdb 检查核心文件gdb -c core a.out;gdb 会话看起来就像进程刚刚崩溃一样。

于 2012-04-17T12:11:23.957 回答
3

这是记忆功能的一个选项,您可以使用mallopt. 通过它的声音,您希望将其设置M_CHECK_ACTION为零以允许继续执行,除非您希望程序立即退出,在这种情况下查看是否2允许您执行您想要的操作。

这个小程序产生正常的glibc错误:test1.c
这个 忽略错误继续进行:test2.c
这个就错误中止:test3.c

于 2012-04-17T11:48:12.563 回答