DEBUGGING MALLOC PROBLEMS
The major difference between this implementation and other allocation implementations is that the free pages are not accessed unless allocated, and are aggressively returned to the kernel for reuse.
Most allocation implementations will store a data structure containing a
linked list in the free chunks of memory,
used to tie all the free memory together.
That can be suboptimal,
as every time the free-list is traversed,
the otherwise unused, and likely paged out,
pages are faulted into primary memory.
On systems which are paging,
this can result in a factor of five increase in the number of page-faults
done by a process.
A side effect of this architecture is that many minor transgressions on the interface which would traditionally not be detected are in fact detected. As a result, programs that have been running happily for years may suddenly start to complain loudly, when linked with this allocation implementation.
The first and most important thing to do is to set the "A" option. This option forces a coredump (if possible) at the first sign of trouble, rather than the normal policy of trying to continue if at all possible.
It is probably also a good idea to recompile the program with suitable options and symbols for debugger support.
If the program starts to give unusual results, coredump or generally behave differently without emitting any of the messages listed in the next section, it is likely because it depends on the storage being filled with zero bytes. Try running it with "Z" option set; if that improves the situation, this diagnosis has been confirmed. If the program still misbehaves, the likely problem is accessing memory outside the allocated area, more likely after than before the allocated area.
Alternatively, if the symptoms are not easy to reproduce, setting the "J" option may help provoke the problem.
In truly difficult cases, the "U" option, if supported by the kernel, can provide a detailed trace of all calls made to these functions.
Unfortunately this implementation does not provide much detail about the problems it detects, the performance impact for storing such information would be prohibitive. There are a number of allocation implementations available on the Net which focus on detecting and pinpointing problems by trading performance for extra sanity checks and detailed diagnostics.
If malloc, calloc, realloc or free detect an error or warning condition, a message will be printed to file descriptor STDERR_FILENO. Errors will result in the process dumping core. If the "A" option is set, all warnings are treated as errors.
The _malloc_message variable allows the programmer to override the function which emits the text strings forming the errors and warnings if for some reason the stderr file descriptor is not suitable for this. Please note that doing anything which tries to allocate memory in this function will assure death of the process.
The following is a brief description of possible error messages and their meanings: