【问题标题】:glibc detect smallbin linked list corruptedglibc 检测 smallbin 链表损坏
【发布时间】:2013-11-01 06:41:08
【问题描述】:

我试图在一个大循环中重复运行一个函数,但在 2 或 3 次迭代后出现错误,但如果我从它给出错误的点开始,它工作正常,但在 3 4 次迭代后再次停止。可能是内存问题。由于函数非常大,我不确定内存泄漏的确切位置。无论如何我可以在每次迭代后释放变量或可以解决这个问题的东西。或者因为它是一个链表内存问题释放所有链表或什么的?有什么解决办法?如果我运行该函数一次,则不会发生该问题,所以我认为这是因为我在循环中重复调用该函数。有没有办法解决这个问题?

错误是

**glibc detected:.....malloc():smallbin double linked list corrupted: 0x000000000 1d404c0 ***

【问题讨论】:

    标签: c++ memory-management memory-leaks


    【解决方案1】:

    库告诉您内存元数据已损坏。仅仅内存泄漏不会发生这种情况,您必须写入无效指针。要么你写的索引越界,要么你写指针被释放后。

    调试此类问题的最简单方法是使用valgrind。它仅适用于 Linux,但您似乎已经在使用它。它相当慢,因为它单步执行程序并检查每条内存访问指令,但它可以捕获无效的内存访问,也可以非常可靠地使用未初始化的变量和内存泄漏。

    还有duma (detect unintended memory access) 库。它也可以在其他平台上运行,速度更快,但它使用更多的内存。

    还有 gcc 自己的 mudflap 可以通过特定的编译器选项激活。那个应该适用于大多数 gcc 目标,但我不确定 C++ 支持有多完整。

    更新 (11/2018):mudflap 大部分被 Google Sanitizers 取代,它们是 Clang 的一部分。

    【讨论】:

    • 我在程序的不同部分遇到了同样的错误,所以我无法确定错误在哪里,我将尝试使用 valgrind。谢谢。
    • @user1583647:损坏通常是伪随机的,标准库仅在实际发生很久之后才检测到它。但是 valgrind 可以在发生无效访问时捕获。
    • 除了程序的标准库,还有什么办法可以解决程序的内存泄漏或内存问题?
    • 我运行了 valgrind,但它给了我一长串错误,其中大多数来自程序中使用的标准库,所以有什么方法可以列出我程序中的内存泄漏,除了使用的标准库?
    • @user1583647:最后一帧是标准库,但几乎可以肯定是由于您对库的错误使用造成的。你必须分析回溯。
    【解决方案2】:

    警告:非常具体的用例

    我在使用 Qt 编写的应用程序中遇到了这个问题,在该应用程序中,我使用了指向从 QObject 派生的对象的指针,该对象具有复制构造函数。我在编译过程中不知何故忽略了以下警告:

    warning: base class ‘class QObject’ should be explicitly initialized in the copy constructor [-Wextra]
    

    原来QObject-派生对象are not supposed to be copied,但没想到我的QObject-派生类上的复制构造函数会导致这种错误。

    【讨论】:

      猜你喜欢
      • 2016-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-10-05
      • 1970-01-01
      • 2013-12-05
      • 1970-01-01
      • 1970-01-01
      • 2015-12-19
      相关资源
      最近更新 更多