2 .\" Copyright (c) 1993 by Thomas Koenig (ig25@rz.uni-karlsruhe.de)
3 .\" and Copyright i2007, 2012, 2018, Michael Kerrisk <mtk.manpages@gmail.com>
5 .\" SPDX-License-Identifier: Linux-man-pages-copyleft
7 .\" Modified Sat Jul 24 19:00:59 1993 by Rik Faith (faith@cs.unc.edu)
8 .\" Clarification concerning realloc, iwj10@cus.cam.ac.uk (Ian Jackson), 950701
9 .\" Documented MALLOC_CHECK_, Wolfram Gloger (wmglo@dent.med.uni-muenchen.de)
10 .\" 2007-09-15 mtk: added notes on malloc()'s use of sbrk() and mmap().
12 .\" FIXME . Review http://austingroupbugs.net/view.php?id=374
13 .\" to see what changes are required on this page.
15 .TH malloc 3 (date) "Linux man-pages (unreleased)"
17 malloc, free, calloc, realloc, reallocarray \- allocate and free dynamic memory
20 .RI ( libc ", " \-lc )
23 .B #include <stdlib.h>
25 .BI "void *malloc(size_t " "size" );
26 .BI "void free(void " "*ptr" );
27 .BI "void *calloc(size_t " "nmemb" ", size_t " "size" );
28 .BI "void *realloc(void " "*ptr" ", size_t " "size" );
29 .BI "void *reallocarray(void " "*ptr" ", size_t " nmemb ", size_t " "size" );
33 Feature Test Macro Requirements for glibc (see
34 .BR feature_test_macros (7)):
41 glibc 2.28 and earlier:
50 bytes and returns a pointer to the allocated memory.
51 .IR "The memory is not initialized" .
56 returns a unique pointer value that can later be successfully passed to
58 (See "Nonportable behavior" for portability issues.)
62 function frees the memory space pointed to by
64 which must have been returned by a previous call to
69 has already been freed, undefined behavior occurs.
72 is NULL, no operation is performed.
76 function allocates memory for an array of
80 bytes each and returns a pointer to the allocated memory.
81 The memory is set to zero.
88 returns a unique pointer value that can later be successfully passed to
91 If the multiplication of
95 would result in integer overflow, then
99 an integer overflow would not be detected in the following call to
101 with the result that an incorrectly sized block of memory would be allocated:
105 malloc(nmemb * size);
111 function changes the size of the memory block pointed to by
116 The contents of the memory
117 will be unchanged in the range from the start of the region
118 up to the minimum of the old and new sizes.
119 If the new size is larger than the old size, the added memory will
125 is NULL, then the call is equivalent to
135 is not NULL, then the call is equivalent to
137 (but see "Nonportable behavior" for portability issues).
141 is NULL, it must have been returned by an earlier call to
143 or related functions.
144 If the area pointed to was moved, a
150 function changes the size of (and possibly moves)
151 the memory block pointed to by
153 to be large enough for an array of
155 elements, each of which is
158 It is equivalent to the call
162 realloc(ptr, nmemb * size);
170 fails safely in the case where the multiplication would overflow.
171 If such an overflow occurs,
181 functions return a pointer to the allocated memory,
182 which is suitably aligned for any type that fits into
183 the requested size or less.
184 On error, these functions return NULL and set
186 Attempting to allocate more than
188 bytes is considered an error, as an object that large
189 could cause later pointer subtraction to overflow.
193 function returns no value, and preserves
200 functions return NULL if
202 is not NULL and the requested size is zero;
203 this is not considered an error.
204 (See "Nonportable behavior" for portability issues.)
205 Otherwise, the returned pointer may be the same as
207 if the allocation was not moved
208 (e.g., there was room to expand the allocation in-place), or different from
210 if the allocation was moved to a new address.
211 If these functions fail,
212 the original block is left untouched; it is not freed or moved.
219 can fail with the following error:
223 Possibly, the application hit the
231 was added in glibc 2.26.
234 and related functions rejected sizes greater than
236 starting in glibc 2.30.
241 starting in glibc 2.33.
243 For an explanation of the terms used in this section, see
251 Interface Attribute Value
257 T} Thread safety MT-Safe
267 POSIX.1-2001, POSIX.1-2008, C99.
270 is a nonstandard extension that first appeared in OpenBSD 5.6 and FreeBSD 11.0.
272 By default, Linux follows an optimistic memory allocation strategy.
275 returns non-NULL there is no guarantee that the memory really
277 In case it turns out that the system is out of memory,
278 one or more processes will be killed by the OOM killer.
279 For more information, see the description of
280 .I /proc/sys/vm/overcommit_memory
282 .I /proc/sys/vm/oom_adj
285 and the Linux kernel source file
286 .IR Documentation/vm/overcommit\-accounting.rst .
290 allocates memory from the heap, and adjusts the size of the heap
293 When allocating blocks of memory larger than
297 implementation allocates the memory as a private anonymous mapping using
300 is 128\ kB by default, but is adjustable using
303 allocations performed using
305 were unaffected by the
308 since Linux 4.7, this limit is also enforced for allocations performed using
311 To avoid corruption in multithreaded applications,
312 mutexes are used internally to protect the memory-management
313 data structures employed by these functions.
314 In a multithreaded application in which threads simultaneously
315 allocate and free memory,
316 there could be contention for these mutexes.
317 To scalably handle memory allocation in multithreaded applications,
318 glibc creates additional
319 .I memory allocation arenas
320 if mutex contention is detected.
321 Each arena is a large region of memory that is internally allocated
327 and managed with its own mutexes.
329 If your program uses a private memory allocator,
330 it should do so by replacing
336 The replacement functions must implement the documented glibc behaviors,
339 handling, size-zero allocations, and overflow checking;
340 otherwise, other library routines may crash or operate incorrectly.
341 For example, if the replacement
345 then seemingly unrelated library routines may
346 fail without having a valid reason in
348 Private memory allocators may also need to replace other glibc functions;
349 see "Replacing malloc" in the glibc manual for details.
351 Crashes in memory allocators
352 are almost always related to heap corruption, such as overflowing
353 an allocated chunk or freeing the same pointer twice.
357 implementation is tunable via environment variables; see
360 .SS Nonportable behavior
362 these functions when the requested size is zero
364 other implementations may return NULL without setting
366 and portable POSIX programs should tolerate such behavior.
370 POSIX requires memory allocators
374 However, the C standard does not require this, and applications
375 portable to non-POSIX platforms should not assume this.
377 Portable programs should not use private memory allocators,
378 as POSIX and the C standard do not allow replacement of
392 #define MALLOCARRAY(n, type) ((type *) my_mallocarray(n, sizeof(type)))
393 #define MALLOC(type) MALLOCARRAY(1, type)
395 static inline void *my_mallocarray(size_t nmemb, size_t size);
402 p = MALLOCARRAY(32, char);
404 err(EXIT_FAILURE, "malloc");
406 strlcpy(p, "foo", 32);
411 my_mallocarray(size_t nmemb, size_t size)
413 return reallocarray(NULL, nmemb, size);
417 .\" http://g.oswego.edu/dl/html/malloc.html
418 .\" A Memory Allocator - by Doug Lea
420 .\" http://www.bozemanpass.com/info/linux/malloc/Linux_Heap_Contention.html
421 .\" Linux Heap, Contention in free() - David Boreham
423 .\" http://www.citi.umich.edu/projects/linux-scalability/reports/malloc.html
424 .\" malloc() Performance in a Multithreaded Linux Environment -
425 .\" Check Lever, David Boreham
433 .BR malloc_get_state (3),
436 .BR malloc_usable_size (3),
440 .BR posix_memalign (3)
442 For details of the GNU C library implementation, see
443 .UR https://sourceware.org/glibc/wiki/MallocInternals