我的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停止我的过程？它是如何工作的？这个腐败检测功能记录在哪里？它具有哪些可调参数以及如何在链接时和/或运行时访问它们？
这有一个安全性,但内容丰富. 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字节/可能/.对于指向Heap发现有意义的东西的4个字节,对于像0x500DF00D这样的标记,可以说是4个字节,对于像0xABCDABCD这样的另一个标记,最后可能是4个字节.
当你做"免费"时,免费可以做几件事.通过查看该指针来查找上下文.测试哨兵的过度/不足并检查双重免费.它如何做到后者.让我们假设第一次免费缓冲区看起来很好.
如果事情看起来不错,它可以执行类似更改0x500DF00D到0x0BADF00D的操作.
所以free()也可以检查BADF00D以检测多次释放尝试.
在分配器中还有许多问题,比如线程安全; 你把这个区块拿回来进行另一次分配等等之前,你还要多长时间停留在那个免费的内存哨兵上......但这是对它如何正常完成的基本解释.