malloc, calloc, realloc, free - 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
free(void *ptr);
char * malloc_options;
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, and the errno
variable is set to ENOMEM.
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
initialized to all bits zero.
The realloc() function changes the size of the previously allocated memory
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 undefined.
If the requested memory cannot be allocated, NULL is returned and
the memory referenced by ptr is valid and unchanged. If ptr is NULL, the
realloc() function behaves identically to malloc() for the specified
size.
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 routines,
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 behavior
is set, or on, and lowercase means that the behavior is not set, or
off.
A All warnings (except for the warning about unknown flags being
set), and failure to allocate memory become fatal. The process
will call abort(3) in these cases.
J Each byte of new memory allocated by malloc() or realloc() as
well as all memory returned by free() or realloc() 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() function to always reallocate 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.
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:
extern char *malloc_options;
malloc_options = "X";
Z This option implicitly sets the ``J'' and ``R'' options, 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
times.
> Double the size of the cache by a factor of two. The default
cache size is 16 pages. This option can be specified multiple
times.
The ``J'' and ``Z'' options are intended for testing and debugging. An
application which changes its behavior when these options are used is
flawed.
The malloc() and calloc() functions return a pointer to the allocated
memory if successful; otherwise a NULL pointer is returned.
The realloc() function returns a pointer, possibly identical to ptr, to
the allocated memory if successful; otherwise a NULL pointer is returned,
in which case the memory referenced by ptr is still available and intact.
The free() function returns no value.
The following environment variables affect the execution of the allocation
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:
extern char *malloc_options;
malloc_options = "X";
DEBUGGING MALLOC PROBLEMS [Toc] [Back] 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 containing
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
implementation.
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 nul 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 following is a brief description of possible error messages and their
meanings:
(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.
allocation failed
If the ``A'' option is specified it is a fatal error for an allocation
function to fail.
mmap(2) failed, check limits
This most likely means that the system is dangerously overloaded
or that the process' limits are incorrectly specified.
freelist is destroyed
The internal free-list has been corrupted.
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 something 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 malloc() or calloc() 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.
out of memory
The ``X'' option was specified and an allocation of memory
failed.
unknown char in MALLOC_OPTIONS
An unknown option was specified. Even with the ``A'' option set,
this warning is still only a warning.
brk(2), alloca(3), getpagesize(3), memory(3)
The malloc(), calloc(), realloc() and free() functions conform to ANSI
X3.159-1989 (``ANSI C'').
The present allocation implementation started out as a filesystem 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, and then in NetBSD 1.5.
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.
This implementation was authored by Poul-Henning Kamp. Please report any
problems to him at <[email protected]>.
BSD August 2, 1999 BSD
[ Back ] |
