The Regents of the University of California. All rights reserved.
This code is derived from software contributed to Berkeley by
the American National Standards Committee X3, on Information
Processing Systems.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. Neither the name of the University nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
@(#)malloc.3 8.1 (Berkeley) 6/4/93
$FreeBSD: head/lib/libc/stdlib/malloc.3 156800 2006-03-17 09:00:27Z jasone $
.Dd March 9, 2006 .Dt MALLOC 3 .Os .Sh NAME .Nm malloc , calloc , realloc , free , reallocf .Nd general purpose memory allocation functions .Sh LIBRARY .Lb libc .Sh SYNOPSIS n stdlib.h .Ft void * .Fn malloc "size_t size" .Ft void * .Fn calloc "size_t number" "size_t size" .Ft void * .Fn realloc "void *ptr" "size_t size" .Ft void * .Fn reallocf "void *ptr" "size_t size" .Ft void .Fn free "void *ptr" .Ft const char * .Va _malloc_options ; .Ft void .Fo \*(lp*_malloc_message\*(rp .Fa "const char *p1" "const char *p2" "const char *p3" "const char *p4" .Fc .Sh DESCRIPTION The .Fn malloc function allocates .Fa size bytes of uninitialized memory. The allocated space is suitably aligned (after possible pointer coercion) for storage of any type of object.
p The .Fn calloc function allocates space for .Fa number objects, each .Fa size bytes in length. The result is identical to calling .Fn malloc with an argument of .Dq "number * size" , with the exception that the allocated memory is explicitly initialized to zero bytes.
p The .Fn realloc function changes the size of the previously allocated memory referenced by .Fa ptr to .Fa 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. Upon success, the memory referenced by .Fa ptr is freed and a pointer to the newly allocated memory is returned. Note that .Fn realloc and .Fn reallocf may move the memory allocation, resulting in a different return value than .Fa ptr . If .Fa ptr is .Dv NULL , the .Fn realloc function behaves identically to .Fn malloc for the specified size.
p The .Fn reallocf function is identical to the .Fn 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.
p The .Fn free function causes the allocated memory referenced by .Fa ptr to be made available for future allocations. If .Fa ptr is .Dv NULL , no action occurs. .Sh 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 allocator implementation.
p The .Dq name of the file referenced by the symbolic link named
a /etc/malloc.conf , the value of the environment variable .Ev MALLOC_OPTIONS , and the string pointed to by the global variable .Va _malloc_options will be interpreted, in that order, character by character as flags.
p 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. l -tag -width indent t A All warnings (except for the warning about unknown flags being set) become fatal. The process will call .Xr abort 3 in these cases. t H Use .Xr madvise 2 when pages within a chunk are no longer in use, but the chunk as a whole cannot yet be deallocated. This is primarily of use when swapping is a real possibility, due to the high overhead of the .Fn madvise system call. t J Each byte of new memory allocated by .Fn malloc , .Fn realloc or .Fn reallocf will be initialized to 0xa5. All memory returned by .Fn free , .Fn realloc or .Fn reallocf will be initialized to 0x5a. This is intended for debugging and will impact performance negatively. t K Increase/decrease the virtual memory chunk size by a factor of two. The default chunk size is 2 MB. This option can be specified multiple times. t 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 times. t P Various statistics are printed at program exit via an .Xr atexit 3 function. This has the potential to cause deadlock for a multi-threaded process that exits while one or more threads are executing in the memory allocation functions. Therefore, this option should only be used with care; it is primarily intended as a performance tuning aid during application development. t Q Increase/decrease the size of the allocation quantum by a factor of two. The default quantum is the minimum allowed by the architecture (typically 8 or 16 bytes). This option can be specified multiple times. t 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. t U Generate .Dq utrace entries for .Xr ktrace 1 , for all operations. Consult the source for details on this option. t V Attempting to allocate zero bytes will return a .Dv 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 .Dq X option. t X Rather than return failure for any allocation function, display a diagnostic message on .Dv stderr and cause the program to drop core (using .Xr abort 3 ) . This option should be set at compile time by including the following in the source code: d -literal -offset indent _malloc_options = "X"; .Ed t Z Each byte of new memory allocated by .Fn malloc , .Fn realloc or .Fn reallocf will be initialized to 0x0. Note that this initialization only happens once for each byte, so .Fn realloc and .Fn reallocf calls do not zero memory that was previously allocated. This is intended for debugging and will impact performance negatively. .El
p The .Dq J and .Dq Z options are intended for testing and debugging. An application which changes its behavior when these options are used is flawed. .Sh RETURN VALUES The .Fn malloc and .Fn calloc functions return a pointer to the allocated memory if successful; otherwise a .Dv NULL pointer is returned and .Va errno is set to .Er ENOMEM .
p The .Fn realloc and .Fn reallocf functions return a pointer, possibly identical to .Fa ptr , to the allocated memory if successful; otherwise a .Dv NULL pointer is returned, and .Va errno is set to .Er ENOMEM if the error was the result of an allocation failure. The .Fn realloc function always leaves the original buffer intact when an error occurs, whereas .Fn reallocf deallocates it in this case.
p The .Fn free function returns no value. .Sh IMPLEMENTATION NOTES 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 completely 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 substantially more arenas than the default is not likely to improve performance, 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.
p Chunks manage their pages by using a power-of-two buddy allocation strategy. Each chunk maintains a page map that makes it possible to determine the state of any page in the chunk in constant time. Allocations that are no larger than one half of a page are managed in groups by page .Dq 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 .Dq 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 quantum-multiple size class (see the .Dq S option) are rounded up to the nearest 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 no larger than half of a chunk (see the .Dq K option), are rounded up to the nearest run size. Allocation requests that are larger than half of a chunk are rounded up to the nearest multiple of the chunk size.
p 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. .Sh DEBUGGING MALLOC PROBLEMS The first thing to do is to set the .Dq 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.
p It is probably also a good idea to recompile the program with suitable options and symbols for debugger support.
p If the program starts to give unusual results, coredump or generally behave 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 .Dq 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.
p Alternatively, if the symptoms are not easy to reproduce, setting the .Dq J option may help provoke the problem.
p In truly difficult cases, the .Dq U option, if supported by the kernel, can provide a detailed trace of all calls made to these functions.
p 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 Internet which focus on detecting and pinpointing problems by trading performance for extra sanity checks and detailed diagnostics. .Sh DIAGNOSTIC MESSAGES 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 .Dq A option is set, all warnings are treated as errors.
p The .Va _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 .Dv 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.
p All messages are prefixed by: l -diag t <progname>: (malloc) .El .Sh ENVIRONMENT The following environment variables affect the execution of the allocation functions: l -tag -width ".Ev MALLOC_OPTIONS" t Ev MALLOC_OPTIONS If the environment variable .Ev MALLOC_OPTIONS is set, the characters it contains will be interpreted as flags to the allocation functions. .El .Sh EXAMPLES To dump core whenever a problem occurs:
p d -literal -offset indent ln -s 'A' /etc/malloc.conf .Ed
p To specify in the source that a program does no return value checking on calls to these functions: d -literal -offset indent _malloc_options = "X"; .Ed .Sh SEE ALSO .Xr madvise 2 , .Xr mmap 2 , .Xr alloca 3 , .Xr atexit 3 , .Xr getpagesize 3 , .Xr memory 3 , .Xr posix_memalign 3 .Sh STANDARDS The .Fn malloc , .Fn calloc , .Fn realloc and .Fn free functions conform to .St -isoC . .Sh HISTORY The .Fn reallocf function first appeared in .Fx 3.0 .