malloc(3)

NAME

malloc, calloc, realloc, free, reallocf - general purpose

memory allocation functions

LIBRARY

Standard C Library (libc, -lc)

SYNOPSIS

#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);
void
free(void *ptr);
const char * _malloc_options;
void
(*_malloc_message)(char *p1, char *p2, char *p3, char *p4);

DESCRIPTION

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
explicitly initialized to zero bytes.

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 mem

ory is undefined. 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 re

turn value than
ptr. If ptr is NULL, the realloc() function behaves identi

cally to
malloc() for the specified size.

The reallocf() function is identical to the realloc() func

tion, except
that it will free the passed pointer when the requested mem

ory cannot be
allocated. This is a FreeBSD specific API designed to ease

the problems
with traditional coding styles for realloc causing memory

leaks in
libraries.

The free() function causes the allocated memory referenced

by ptr to be
made available for future allocations. If ptr is NULL, no

action occurs.

TUNING

Once, when the first call is made to one of these memory al

location 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 MAL

LOC_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) become fatal. The process will call abort(3)

in these
cases.

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 op

tions 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 al

ways reallo

cate memory even if the initial allocation was suf

ficiently
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. This option is

incompatible
with the ``X'' option.

X Rather than return failure for any allocation func

tion, display a

diagnostic message on stderr and cause the program

to drop core
(using abort(3)). This option should be set at com

pile time by
including the following in the source code:

_malloc_options = "X";

Z This option implicitly sets the ``J'' and ``R'' op

tions, 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 speci

fied multiple
times.

> Double the size of the cache by a factor of two.

The default

cache size is 16 pages. This option can be speci

fied multiple
times.

The ``J'' and ``Z'' options are intended for testing and de

bugging. An
application which changes its behavior when these options

are used is
flawed.

RETURN VALUES

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 identical 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
result of an allocation failure. The realloc() function al

ways leaves
the original buffer intact when an error occurs, whereas

reallocf() deallocates it in this case.

The free() function returns no value.

DEBUGGING MALLOC PROBLEMS

The major difference between this implementation and other

allocation
implementations is that the free pages are not accessed un

less 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 sys

tems 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 trans

gressions on
the interface which would traditionally not be detected are

in fact
detected. As a result, programs that have been running hap

pily 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 zero 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 de

tail about the
problems it detects, the performance impact for storing such

information
would be prohibitive. There are a number of allocation im

plementations
available on the 'Net which focus on detecting and pinpoint

ing problems
by trading performance for extra sanity checks and detailed

diagnostics.

DIAGNOSTIC MESSAGES

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 over

ride the function 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 mes

sages 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 infor

mation.

mmap(2) failed, check limits This most likely means that

the system is
dangerously overloaded or that the process' limits are in

correctly specified.

freelist is destroyed The internal free-list has been cor

rupted.

out of memory The ``X'' option was specified and an alloca

tion of memory
failed.

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 alloca

tion functions
points outside the bounds of the memory of which they are

aware.

malloc() has never been called No memory has been allocat

ed, 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 free(), realloc(),

or reallocf()
is trying to free does not reference a possible page.

recursive call A process has attempted to call an alloca

tion 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 speci

fied. Even
with the ``A'' option set, this warning is still only a

warning.

ENVIRONMENT

The following environment variables affect the execution of

the allocation functions:

MALLOC_OPTIONS If the environment variable MALLOC_OP

TIONS is set,

the characters it contains will be in

terpreted as
flags to the allocation functions.

EXAMPLES

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

SEE ALSO

brk(2), mmap(2), alloca(3), getpagesize(3), memory(3)
/usr/share/doc/papers/malloc.ascii.gz

STANDARDS

The malloc(), calloc(), realloc() and free() functions con

form to ISO/IEC
9899:1990 (``ISO C89'').

HISTORY

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.

AUTHORS

Poul-Henning Kamp <phk@FreeBSD.org>

BUGS

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.

BSD August 19, 2004

BSD