How can malloc() cause a SIGSEGV?

Question

I have an odd bug in my program, it appears to me that malloc() is causing a SIGSEGV, which as far as my understanding goes does not make any sense. I am using a library cal

Answer 1

The code is problematic. If malloc returns NULL, this case is not handled correctly in your code. You simply assume that memory has been allocated for you when it actually has not been. This can cause memory corruption.

Answer 2

Probably memory violation occurs in other part of your code. If you are on Linux, you should definitely try valgrind. I would never trust my own C programs unless it passes valgrind.

EDIT: another useful tool is Electric fence. Glibc also provides the MALLOC_CHECK_ environmental variable to help debug memory problems. These two methods do not affect running speed as much as valgrind.

Answer 3

You probably have corrupted you heap somewhere before this call by a buffer overflow or by calling free with a pointer that wasn't allocated by malloc (or that was already freed).

If the internal data structures used by malloc get corrupted this way, malloc is using invalid data and might crash.

Answer 4

malloc can segfault for example when the heap is corrupted. Check that you are not writing anything beyond the bounds of any previous allocation.

Answer 5

There are a myriad ways of triggering a core dump from malloc() (and realloc() and calloc()). These include:

• Buffer overflow: writing beyond the end of the allocated space (trampling control information that malloc() was keeping there).
• Buffer underflow: writing before the start of the allocated space (trampling control information that malloc() was keeping there).
• Freeing memory that was not allocated by malloc(). In a mixed C and C++ program, that would include freeing memory allocated in C++ by new.
• Freeing a pointer that points part way through a memory block allocated by malloc() - which is a special case of the previous case.
• Freeing a pointer that was already freed - the notorious 'double free'.

Using a diagnostic version of malloc() or enabling diagnostics in your system's standard version, may help identify some of these problems. For example, it may be able to detect small underflows and overflows (because it allocates extra space to provide a buffer zone around the space that you requested), and it can probably detect attempts to free memory that was not allocated or that was already freed or pointers part way through the allocated space - because it will store the information separately from the allocated space. The cost is that the debugging version takes more space. A really good allocator will be able to record the stack trace and line numbers to tell you where the allocation occurred in your code, or where the first free occurred.

Answer 6

You should try to debug this code in isolation, to see if the problem is actually located where the segfault is generated. (I suspect that it is not).

This means:

#1: Compile the code with -O0, to make sure that gdb gets correct line numbering information.

#2: Write a unit test which calls this part of the code.

My guess is that the code will work correctly when used separately. You can then test your other modules in the same way, until you find out what causes the bug.

Using Valgrind, as others have suggested, is also a very good idea.