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 回答