我的Linux 3.0 / glibc 2.13应用程序正在停止，并出现以下错误：
*** 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停止我的过程？它是如何工作的？这个腐败检测功能记录在哪里？它具有哪些可调参数以及如何在链接时和/或运行时访问它们？
答案 0 :(得分：5)
这有一个安全性，但内容丰富。 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字节，则在32位系统中分配1012字节/可能/。比如4个字节用于指向Heap发现有意义的东西，4个字节用于像0x500DF00D这样的标记，最后可能是4个字节用于另一个标记，如0xABCDABCD。
当你做“免费”时，免费可以做几件事。通过查看该指针来查找上下文。测试哨兵的过度/不足并检查双重免费。它如何做到后者。让我们假设第一次免费缓冲区看起来很好。
如果事情看起来不错，可以做一些改变0x500DF00D到0x0BADF00D的事情。
所以free（）也可以检查BADF00D以检测多次释放尝试。
分配器中还有许多问题，比如线程安全;你把这个区块拿回来进行另一次分配等等之前，你还要多久坚持那个免费的内存哨兵......但这是对它如何正常完成的基本解释。