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, malloc_usable_size -- general
     purpose memory allocation 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)(const char *p1,	const char *p2,	const char *p3,
	 const char *p4);

     #include <malloc_np.h>

     malloc_usable_size(const void *ptr);

     The malloc() function allocates size bytes	of uninitialized memory.  The
     allocated space is	suitably aligned (after	possible pointer coercion) for
     storage of	any type of object.

     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.  Upon success, 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 re-
     turn 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.

     The malloc_usable_size() function returns the usable size of the alloca-
     tion pointed to by	ptr.  The return value may be larger than the size
     that was requested	during allocation.  The	malloc_usable_size() function
     is	not a mechanism	for in-place realloc();	rather it is provided solely
     as	a tool for introspection purposes.  Any	discrepancy between the	re-
     quested allocation	size and the size reported by malloc_usable_size()
     should not	be depended on,	since such behavior is entirely	implementa-

     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 allocator 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

     H	     Use madvise(2) when pages within a	chunk are no longer in use,
	     but the chunk as a	whole cannot yet be deallocated.  This is pri-
	     marily of use when	swapping is a real possibility,	due to the
	     high overhead of the madvise() system call.

     J	     Each byte of new memory allocated by malloc(), realloc() or
	     reallocf()	will be	initialized to 0xa5.  All memory returned by
	     free(), realloc() or reallocf() will be initialized to 0x5a.
	     This is intended for debugging and	will impact performance	nega-

     K	     Increase/decrease the virtual memory chunk	size by	a factor of
	     two.  The default chunk size is 1 MB.  This option	can be speci-
	     fied multiple times.

     N	     Increase/decrease the number of arenas by a factor	of two.	 The
	     default number of arenas is four times the	number of CPUs,	or one
	     if	there is a single CPU.	This option can	be specified multiple

     P	     Various statistics	are printed at program exit via	an atexit(3)
	     function.	This has the potential to cause	deadlock for a multi-
	     threaded process that exits while one or more threads are execut-
	     ing in the	memory allocation functions.  Therefore, this option
	     should only be used with care; it is primarily intended as	a per-
	     formance tuning aid during	application development.

     Q	     Increase/decrease the size	of the allocation quantum by a factor
	     of	two.  The default quantum is the minimum allowed by the	archi-
	     tecture (typically	8 or 16	bytes).	 This option can be specified
	     multiple times.

     S	     Increase/decrease the size	of the maximum size class that is a
	     multiple of the quantum by	a factor of two.  Above	this size,
	     power-of-two spacing is used for size classes.  The default value
	     is	512 bytes.  This option	can be specified multiple times.

     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	     Each byte of new memory allocated by malloc(), realloc() or
	     reallocf()	will be	initialized to 0.  Note	that this initializa-
	     tion only happens once for	each byte, so realloc()	and reallocf()
	     calls do not zero memory that was previously allocated.  This is
	     intended for debugging and	will impact performance	negatively.

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

     Traditionally, allocators have used sbrk(2) to obtain memory, but this
     implementation uses mmap(2), and only uses	sbrk(2)	under limited circum-
     stances, and only for 32-bit architectures.  As a result, the datasize
     resource limit has	little practical effect	for typical applications.  The
     vmemoryuse	resource limit,	however, can be	used to	bound the total	vir-
     tual memory used by a process, as described in limits(1).

     This allocator uses multiple arenas in order to reduce lock contention
     for threaded programs on multi-processor systems.	This works well	with
     regard to threading scalability, but incurs some costs.  There is a small
     fixed per-arena overhead, and additionally, arenas	manage memory com-
     pletely independently of each other, which	means a	small fixed increase
     in	overall	memory fragmentation.  These overheads are not generally an
     issue, given the number of	arenas normally	used.  Note that using sub-
     stantially	more arenas than the default is	not likely to improve perfor-
     mance, mainly due to reduced cache	performance.  However, it may make
     sense to reduce the number	of arenas if an	application does not make much
     use of the	allocation functions.

     Memory is conceptually broken into	equal-sized chunks, where the chunk
     size is a power of	two that is greater than the page size.	 Chunks	are
     always aligned to multiples of the	chunk size.  This alignment makes it
     possible to find metadata for user	objects	very quickly.

     User objects are broken into three	categories according to	size: small,
     large, and	huge.  Small objects are no larger than	one half of a page.
     Large objects are smaller than the	chunk size.  Huge objects are a	multi-
     ple of the	chunk size.  Small and large objects are managed by arenas;
     huge objects are managed separately in a single data structure that is
     shared by all threads.  Huge objects are used by applications infre-
     quently enough that this single data structure is not a scalability is-

     Each chunk	that is	managed	by an arena tracks its contents	in a page map
     as	runs of	contiguous pages (unused, backing a set	of small objects, or
     backing one large object).	 The combination of chunk alignment and	chunk
     page maps makes it	possible to determine all metadata regarding small and
     large allocations in constant time.

     Small objects are managed in groups by page runs.	Each run maintains a
     bitmap that tracks	which regions are in use.  Allocation requests that
     are no more than half the quantum (see the	"Q" option) are	rounded	up to
     the nearest power of two (typically 2, 4, or 8).  Allocation requests
     that are more than	half the quantum, but no more than the maximum quan-
     tum-multiple size class (see the "S" option) are rounded up to the	near-
     est multiple of the quantum.  Allocation requests that are	larger than
     the maximum quantum-multiple size class, but no larger than one half of a
     page, are rounded up to the nearest power of two.	Allocation requests
     that are larger than half of a page, but small enough to fit in an	arena-
     managed chunk (see	the "K"	option), are rounded up	to the nearest run
     size.  Allocation requests	that are too large to fit in an	arena-managed
     chunk are rounded up to the nearest multiple of the chunk size.

     Allocations are packed tightly together, which can	be an issue for	multi-
     threaded applications.  If	you need to assure that	allocations do not
     suffer from cache line sharing, round your	allocation requests up to the
     nearest multiple of the cache line	size.

     The first 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 nor-
     mal 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 mentioned in	the
     next section, it is likely	because	it depends on the storage being	filled
     with zero bytes.  Try running it with the "Z" option set; if that im-
     proves the	situation, this	diagnosis has been confirmed.  If the program
     still misbehaves, the likely problem is accessing memory outside the al-
     located 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 allocator implementations
     available on the Internet which focus on detecting	and pinpointing	prob-
     lems by trading performance for extra sanity checks and detailed diagnos-

     If	any of the memory allocation/deallocation functions 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
     is	likely to result in a crash or deadlock.

     All messages are prefixed by "<progname>: (malloc)".

     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 malloc_usable_size() function returns the usable size of the alloca-
     tion pointed to by	ptr.

     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	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";

     limits(1),	madvise(2), mmap(2), sbrk(2), alloca(3), atexit(3),
     getpagesize(3), memory(3),	posix_memalign(3)

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

     The reallocf() function first appeared in FreeBSD 3.0.

     The malloc_usable_size() function first appeared in FreeBSD 7.0.

BSD				 June 15, 2007				   BSD


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

home | help