Linux 3.0: "glibc error encountered" - corruption detected?
My Linux 3.0 / glibc 2.13 application stops with an error of the following form:
*** 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]
My question is not about the error that caused this.
My question is, is glibc's corruption detection feature stopping my process? How it works? Where is this corruption detection feature registered? What configurable options are available and how are they available at link time and / or runtime?
source to share
It has its own security, but it is very rich. http://www.blackhat.com/presentations/bh-usa-07/Ferguson/Whitepaper/bh-usa-07-ferguson-WP.pdf
Here is the glibc documentation on interacting with the system: http://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-Checking.html
Short answer: Heap allocation implementations typically insert watchdog values before (and sometimes after) the returned memory.
As a bogus example explaining the point, if you request 1000 bytes, 1012 bytes / can be allocated on a 32-bit system. Say 4 bytes for a pointer to something the heap finds significant, 4 bytes for a watchdog like 0x500DF00D, and maybe 4 bytes at the end for another sentry like 0xABCDABCD.
When you do "for free," then there are several things you can do for free. Find context by looking at this pointer. Test sentries for underrun and double freedom. As the latter does. Let's assume the buffer looked good on the 1st free one.
If everything looks good, it might do something like changing 0x500DF00D to 0x0BADF00D.
So free () can also check for the presence of BADF00D to detect multiple free attempts.
There are many more issues with the allocator, such as thread safety; how long do you hang on this free sentinel memory before giving this block back for another allocation, etc. But this is the main explanation for how this is usually done.
source to share