强制coredump上glib自由错误

我运行我的程序时出现以下错误，它不会在gdb下发生。我如何强制glibc或ubuntu转储核心放弃？我尝试了“ulimit -c unlimited”。但是，这不是一个seg故障，也不是运气。另外，我在valgrind修复中有太多内存错误，所有这些都会花费很多时间。强制coredump上glib自由错误

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

* glibc的检测 ./main：免费（）：无效的下一个尺寸（快速）：0x0000000000ae0560 * *

编辑无论如何，我发现究竟是什么造成的valgrind这个glibc的腐败。只是保持开放，看看是否有可能。

来源

2011-04-26 user357689

您可能有堆损坏或“双重释放”或内存管理的另一个问题 - 一种问题，你应该尽快解决而不是修补。 – sharptooth 2011-04-26 07:21:42

重复的http://stackoverflow.com/questions/151268 btw ...？ – 0xC0000022L 2011-04-26 11:30:08

这不是重复的。默认情况下，glibc在我的ubuntu中中止。我想要的是一个coredump文件，当它中止时。 – user357689 2011-04-26 16:57:08

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

如果您使用普通版本，可能会有一个（Valgrind）软件包可用于您的发行版。

创建核心转储的唯一方法是在发生之前将GDB附加到进程。但是，这仍然不会让你更接近导致问题的解决方案。 Valgrind是最好的方法。

来源

2011-04-26 11:19:50 0xC0000022L

我说我在使用valgrind，而且在我的第一个问题中我有很多错误（2k +）。这个库不是我的代码。所以，我想从一些关键问题开始，然后走下去，因此希望从gdb中获得coredump。 – user357689 2011-04-26 16:55:31

@ user357689：Valgrind中的错误并不总是必须首先出现错误（这就是忽略文件存在的原因），其次，一个根本原因通常会导致数百条出错的行。不过，只有根本原因是相关的。固定时，下一次运行通常会有相当少的错误。注意：重要的部分（因此强调）是错误应该是固定的，而不是仅仅被诊断。随时投入学习Valgrind及其产出不会被浪费。 – 0xC0000022L 2011-04-26 17:01:03

从glibc的documentation：

如果MALLOC_CHECK_被设置为0，任何检测到堆损坏被自动忽略;如果设置为1，则在stderr上打印诊断;如果设置为2，立即调用abort。

调用abort()通常产生核心转储（根据ulimit -c设置）。

来源

2011-05-15 18:16:32

强制coredump上glib自由错误

回答

相关问题