Linux 3.0：“检测到glibc”中止 - 调整检测到的损坏功能？

Question

我的Linux 3.0/2.13 glibc的应用程序是用以下形式的错误停止：

*** glibc detected *** MYAPP: double free or corruption (fasttop): 0x000000000164fef0 *** 
======= Backtrace: ========= 
/lib/x86_64-linux-gnu/libc.so.6(+0x78a96)[0x7f9b114d4a96] 
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x7f9b114d8d7c] 
MYAPP(...+0x131)[0x44e4c1] 
MYAPP(...+0x3e8)[0x4441d8] 
MYAPP(...+0x61)[0x440e41] 

我的问题是不有关导致这个错误。

我的问题是什么“腐败检测”功能是glibc停止我的过程？它是如何工作的？此腐败检测功能在哪里记录？它具有哪些可调参数以及它们在链接时和/或运行时如何访问？

Answer 1

这有一个安全性，但内容非常丰富。 http://www.blackhat.com/presentations/bh-usa-07/Ferguson/Whitepaper/bh-usa-07-ferguson-WP.pdf

这里是glibc的对与系统交互文档： http://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-Checking.html

简短的回答：堆分配的 实现通常在他们返回（后有时）内存的正面坚持定点值。

作为一个假的例子，说明了这一点，如果你要求1000字节，1012字节/可能/在32位系统中分配。说4个字节指向Heap发现有意义的指针，4个字节指向像0x500DF00D这样的标记，并且可能在结束时指定4个字节指向另一个指针，如0xABCDABCD。

当你做一个'免费'，那么免费可以做几件事情。通过查看该指针来查找上下文。测试哨兵的过度/不足，并检查双重免费。它是如何做后者的。假设1号空闲缓冲区看起来不错。

如果事情看起来不错，它可以做一些改变0x500DF00D到0x0BADF00D。

所以free（）也可以检查BADF00D以检测多次释放尝试。

还有很多问题，如分配器中的线程安全问题;在你把这个块交给另外一个分配之前，你在这个free'd memory sentinel上挂了多久？等等......但是这是对它如何正常完成的基本解释。