MALLOC (3) | | Unix Manual Pages

MALLOC (3) | | Unix Manual Pages | :man▋

Note that malloc does NOT normally initialize the returned memory to zero bytes.

The calloc function allocates space for number objects, each size bytes in length. The result is identical to calling malloc with an argument of ""number * size"", with the exception that the allocated memory is explicitly initialized to zero bytes.

The realloc function changes the size of the previously allocated memory referenced by ptr to size bytes. The contents of the memory are unchanged up to the lesser of the new and old sizes. If the new size is larger, the value of the newly allocated portion of the memory is undefined. If the requested memory cannot be allocated, NULL is returned and the memory referenced by ptr is valid and unchanged. If memory can be allocated, the memory referenced by ptr is freed and a pointer to the newly allocated memory is returned. Note that realloc and reallocf may move the memory allocation resulting in a different return value than ptr. If ptr is NULL, the realloc function behaves identically to malloc for the specified size.

The reallocf function is identical to the realloc function, except that it will free the passed pointer when the requested memory cannot be allocated. This is a
.Fx specific API designed to ease the problems with traditional coding styles for realloc causing memory leaks in libraries.

The free function causes the allocated memory referenced by ptr to be made available for future allocations. If ptr is NULL, no action occurs.

TUNING

Once, when the first call is made to one of these memory allocation routines, various flags will be set or reset, which affect the workings of this allocation implementation.

The ‘‘name’’ of the file referenced by the symbolic link named /etc/malloc.conf, the value of the environment variable MALLOC_OPTIONS, and the string pointed to by the global variable _malloc_options will be interpreted, in that order, character by character as flags.

Most flags are single letters, where uppercase indicates that the behavior is set, or on, and lowercase means that the behavior is not set, or off.

A	All warnings (except for the warning about unknown flags being set) become fatal. The process will call abort(3) in these cases.
J	Each byte of new memory allocated by `malloc`, `realloc` or `reallocf` as well as all memory returned by `free`, `realloc` or `reallocf` will be initialized to 0xd0. This options also sets the "R" option. This is intended for debugging and will impact performance negatively.
H	Pass a hint to the kernel about pages unused by the allocation functions. This will help performance if the system is paging excessively. This option is off by default.
R	Causes the `realloc` and `reallocf` functions to always reallocate memory even if the initial allocation was sufficiently large. This can substantially aid in compacting memory.
U	Generate "utrace" entries for ktrace(1), for all operations. Consult the source for details on this option.
V	Attempting to allocate zero bytes will return a `NULL` pointer instead of a valid pointer. (The default behavior is to make a minimal allocation and return a pointer to it.) This option is provided for System V compatibility. This option is incompatible with the "X" option.
X	Rather than return failure for any allocation function, display a diagnostic message on `stderr` and cause the program to drop core (using abort(3)). This option should be set at compile time by including the following in the source code: _malloc_options = "X";
Z	This option implicitly sets the "J" and "R" options, and then zeros out the bytes that were requested. This is intended for debugging and will impact performance negatively.
<	Reduce the size of the cache by a factor of two. The default cache size is 16 pages. This option can be specified multiple times.
>	Double the size of the cache by a factor of two. The default cache size is 16 pages. This option can be specified multiple times.

The "J" and "Z" options are intended for testing and debugging. An application which changes its behavior when these options are used is flawed.

RETURN VALUES

The malloc and calloc functions return a pointer to the allocated memory if successful; otherwise a NULL pointer is returned and errno is set to ENOMEM.

The realloc and reallocf functions return a pointer, possibly identical to ptr, to the allocated memory if successful; otherwise a NULL pointer is returned, and errno is set to ENOMEM if the error was the result of an allocation failure. The realloc function always leaves the original buffer intact when an error occurs, whereas reallocf deallocates it in this case.

The free function returns no value.

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.

DIAGNOSTIC MESSAGES

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:

"(ES): mumble mumble mumble"	The allocation functions were compiled with "EXTRA_SANITY" defined, and an error was found during the additional error checking. Consult the source code for further information.
"mmap(2) failed, check limits"	This most likely means that the system is dangerously overloaded or that the process’ limits are incorrectly specified.
"freelist is destroyed"	The internal free-list has been corrupted.
"out of memory"	The "X" option was specified and an allocation of memory failed.

The following is a brief description of possible warning messages and their meanings:

"chunk/page is already free"	The process attempted to `free` memory which had already been freed.
"junk pointer, ..."	A pointer specified to one of the allocation functions points outside the bounds of the memory of which they are aware.
"malloc() has never been called"	No memory has been allocated, yet something is being freed or realloc’ed.
"modified (chunk-/page-) pointer"	The pointer passed to `free` or `realloc` has been modified.
"pointer to wrong page"	The pointer that `free`, `realloc`, or `reallocf` is trying to free does not reference a possible page.
"recursive call"	A process has attempted to call an allocation function recursively. This is not permitted. In particular, signal handlers should not attempt to allocate memory.
"unknown char in MALLOC_OPTIONS"	An unknown option was specified. Even with the "A" option set, this warning is still only a warning.