Linux 3.0: "glibc detected" abort - tuning corruption detected feature?

Question

My Linux 3.0 / glibc 2.13 application is stopping 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 bug that caused this.

My question is by what "corruption detection" feature is glibc halting my process? How does it work? Where is this corruption detection feature documented? What tunable parameters does it have and how are they accessed at link-time and/or run-time?

Answer 1

This has a security bent to it, but is very content rich. http://www.blackhat.com/presentations/bh-usa-07/Ferguson/Whitepaper/bh-usa-07-ferguson-WP.pdf

Here is glibc's documentation on interacting with the system: http://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-Checking.html

The short answer: Implementations of heap allocation typically stick sentinel values in front of the memory they return (and sometimes after it).

As a fake example that explains the point, if you ask for 1000 bytes, 1012 bytes /might/ be allocated in a 32 bit system. Say 4 bytes for a pointer to something the Heap finds meaningful, 4 bytes for a sentinel like 0x500DF00D, and maybe 4 bytes at the end for another sentinel like 0xABCDABCD.

When you do a 'free', then free can do several things. Find context by looking at that pointer. Test the sentinels for over/underrun and check for double free. How does it do the latter. Let's assume the buffer looked good on the 1st free.

If things look good, it can do something like change 0x500DF00D to 0x0BADF00D.

So free() can also check for BADF00D to detect multiple attempts to free.

There are many more issues like thread safety in the allocator; how long do you hang onto that free'd memory sentinel before you hand that block back out for another allocation, etc... But that's a basic explanation of how it's normally done.