在 glib free 错误上强制 coredump答案

【问题标题】：force coredump on glib free error在 glib free 错误上强制 coredump
【发布时间】：2011-08-12 19:58:07
【问题描述】：

我在运行我的程序时收到以下错误，但在 gdb 下不会发生。如何强制 glibc 或 ubuntu 在中止时转储核心？我试过“ulimit -c 无限”。但是，这不是一个段错误，也不是运气。另外，我在 valgrind 中有太多内存错误，修复所有这些错误需要很长时间。

另外，将 MALLOC_CHECK_ 设置为 0 不会强制程序退出。但是，这不是我的选择。

* 检测到 glibc ./main: free(): invalid next size (fast): 0x0000000000ae0560 **

编辑无论如何，我发现究竟是什么导致了 valgrind 中的这种 glibc 损坏。只是保持开放，看看是否有可能。

【问题讨论】：

【解决方案1】：

使用Valgrind 诊断并修复问题。它会更快更直接，因为这确实看起来像是典型的堆损坏。

如果您使用通用软件包，您的发行版可能有一个 (Valgrind) 软件包可用。

创建核心转储的唯一其他方法是在 GDB 发生之前将其附加到进程。但这仍然不能让您更接近解决问题的原因。 Valgrind 是更好的方法。

【讨论】：

我说我使用的是 valgrind，并且在我最初的问题中出现了很多错误（2k+）。这是这个库而不是我的代码。所以，我想从一些关键问题开始，然后走下去，因此想要从 gdb 中转出 coredump。
@user357689：Valgrind 中的错误并不总是首先是错误（这就是存在忽略文件的原因），其次，一个根本原因通常会导致数百行错误。不过，只有根本原因是相关的。修复后，下一次运行的错误通常会大大减少。注意：重要的部分（因此强调）是应该修复错误，而不仅仅是诊断。投入学习 Valgrind 的任何时间都不会浪费。

【解决方案2】：

来自 glibc documentation:

如果 MALLOC_CHECK_ 设置为 0，任何检测到的堆损坏都会被静默忽略；如果设置为 1，则在 stderr 上打印诊断信息；如果设置为 2，则立即调用 abort。

调用abort() 通常会产生核心转储（取决于ulimit -c 设置）。

【讨论】：