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

FreeBSD Manual Pages


home | help
MALLOC(3)		 BSD 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 ex-
     plicitly 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 un-
     changed 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	li-

     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 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 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 in-
	     stead 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 ze-
	     ros out the bytes that were requested.  This is intended for de-
	     bugging 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 ap-
     plication 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 re-
     sult of an	allocation failure.  The realloc() function always leaves the
     original buffer intact when an error occurs, whereas reallocf() deallo-
     cates it in this case.

     The free()	function returns no value.

     The major difference between this implementation and other	allocation im-
     plementations 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 de-
     tected.  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 be-
     have 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 mis-
     behaves, 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 er-
     ror 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 ac-
     tual values.

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

BSD				August 19, 2004				   BSD


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

home | help