c malloc questions (mem corruption)

Question

When using malloc, if it produces a core dump with the error:

malloc(): memory corruption: ....... ***

Does this mean that malloc tried to allocate memory that was not free to allocate? IF so what are the causes of this?

Answer 1

It completely depends on your malloc implementation, but usually what this is means is that at some point prior to that malloc something wrote more data to a malloced buffer than its size.

A lot of malloc implementations store some of their data inline with their memory, in other words:

+--------------------------------+
|14 bytes -> Padding             | 
+--------------------------------+
|2 bytes -> Internal malloc info |
+--------------------------------+
|6 bytes -> Your data            |
+--------------------------------+
|8 bytes -> Padding              |
+--------------------------------+
|2 bytes -> Internal malloc info |
+--------------------------------+

So if some code of yours or a library wrote 16 bytes to that 6 byte buffer it would overwrite the padding and the 2 bytes of internal malloc info. The next time you call malloc it will try to walk through its data to find space, hit the overwritten space, and it will be nonsensical since you overwrote it, corrupting the heap.

Depending on the implementation such an error could also be caused by making a double free.

Answer 2

The usual cause of this is that you wrote over data that malloc() did not give you permission to write over - either buffer overrun (writing beyond the end of the space you were given) or buffer underrun (writing before the start of the buffer).

It can sometimes be caused by freeing a pointer that was not allocated by malloc() et al, or by re-freeing (double freeing) a pointer that was allocated by malloc(). For example, freeing a static buffer is a bad idea; you will get corruption.

You should assume that the problem is in your code - it is extremely unlikely to be a problem in malloc() et al, and rather unlikely to be in any other library you are using.

Answer 3

Most likely, this is not a problem in malloc itself. Rather, this is a problem with your application modifying parts of the heap that it shouldn't.

If you are running on Linux, try using Valgrind to see which code is trashing your heap.

Answer 4

Could you please provide your malloc() statement?

Also, I wanted to double check that the return value is not null?

Outside of not having the memory to allocate to begin with, the problems I have encountered when using malloc() or new similar the nature you mentioned where actually resultant of a corrupted heap. I usually found some "interesting" code elsewhere in the program doing soomething like memcpy() with a character buffer causing a buffer overrun and a mangled address space.

-bn

Answer 5

There are several things that are usual causes of heap corruption:

• overrunning the memory allocation (writing past the end of the allocated block)
• double freeing a block
• using a pointer after it's been freed
• and of course something writing erroneously through a pointer that has nothing to do with a previous allocation (a 'ram hit' or rogue pointer) - this is the general case that includes all of the above.

These problems can be difficult to debug because the cause and effect are often separated by time and space (different area of code). So the bug doesn't get noticed until an eternity (in computer time) passes after the bug that caused the problem executes.

Using a debug heap can be very helpful in debugging these issues. Microsoft's compilers have a CrtDebug heap that's enabled in debug builds (but can have additional configuration items set). I'm not sure what GCC has out of the box, but there are tools I'm familiar with in passing such as Valgrind and Electric Fence that might help. Finally there a ton of home-grown heap debug libraries that might be helpful (Google around).