Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
MALLOC(3)              FreeBSD Library Functions Manual              MALLOC(3)

     malloc, calloc, realloc, free, reallocf -- general purpose memory alloca-
     tion functions

     Standard C Library (libc, -lc)

     #include <stdlib.h>

     void *
     malloc(size_t size);

     void *
     calloc(size_t number, size_t size);

     void *
     realloc(void *ptr, size_t size);

     void *
     reallocf(void *ptr, size_t size);

     free(void *ptr);

     const char * _malloc_options;

     (*_malloc_message)(char *p1, char *p2, char *p3, char *p4);

     The malloc() function allocates size bytes of memory.  The allocated
     space is suitably aligned (after possible pointer coercion) for storage
     of any type of object.  If the space is at least pagesize bytes in length
     (see getpagesize(3)), the returned memory will be page boundary aligned
     as well.  If malloc() fails, a NULL pointer is returned.

     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 mem-
     ory 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 unde-
     fined.  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 FreeBSD specific API designed to ease the problems
     with traditional coding styles for realloc causing memory leaks in

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

     Once, when the first call is made to one of these memory allocation rou-
     tines, 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 behav-
     ior is set, or on, and lowercase means that the behavior is not set, or

     A       All warnings (except for the warning about unknown flags being
             set) become fatal.  The process will call abort(3) in these

     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 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 reallo-
             cate 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'' option, 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

     >       Double the size of the cache by a factor of two.  The default
             cache size is 16 pages.  This option can be specified multiple

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

     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 identi-
     cal 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() deal-
     locates it in this case.

     The free() function returns no value.

     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 con-
           taining 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

     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 func-
     tion 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

     (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 speci-

     freelist is destroyed  The internal free-list has been corrupted.

     out of memory  The ``X'' option was specified and an allocation of memory

     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 some-
     thing 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.

     The following environment variables affect the execution of the alloca-
     tion functions:

     MALLOC_OPTIONS  If the environment variable MALLOC_OPTIONS is set, the
                     characters it contains will be interpreted as flags to
                     the allocation functions.

     To set a systemwide reduction of cache size, and to dump core whenever a
     problem occurs:

           ln -s 'A<' /etc/malloc.conf

     To specify in the source that a program does no return value checking on
     calls to these functions:

           _malloc_options = "X";

     brk(2), mmap(2), alloca(3), getpagesize(3), memory(3)

     The malloc(), calloc(), realloc() and free() functions conform to ISO/IEC
     9899:1990 (``ISO C90'').

     The present allocation implementation started out as a file system for a
     drum attached to a 20bit binary challenged computer which was built with
     discrete germanium transistors.  It has since graduated to handle primary
     storage rather than secondary.  It first appeared in its new shape and
     ability in FreeBSD 2.2.

     The reallocf() function first appeared in FreeBSD 3.0.

     Poul-Henning Kamp <>

     The messages printed in case of problems provide no detail about the
     actual values.

     It can be argued that returning a NULL pointer when asked to allocate
     zero bytes is a silly response to a silly question.

FreeBSD 6.2                      June 21, 2006                     FreeBSD 6.2


Want to link to this manual page? Use this URL:

home | help