|BRK(2)||System Calls Manual||BRK(2)|
change data segment size
Standard C Library (libc, -lc)
sbrk() functions are legacy interfaces from before the advent of modern virtual memory management. They are deprecated and not present on the arm64 or riscv architectures. The mmap(2) interface should be used to allocate pages instead.
sbrk() functions are used to change the amount of
memory allocated in a process's data segment. They do this by moving the
location of the “break”. The break is the first address after
the end of the process's uninitialized data segment (also known as the
function sets the break to addr.
function raises the break by incr bytes, thus
allocating at least incr bytes of new memory in the
data segment. If incr is negative, the break is
lowered by incr bytes.
While the actual process data segment size maintained by the kernel will only grow or shrink in page sizes, these functions allow setting the break to unaligned values (i.e., it may point to any address inside the last page of the data segment).
The getrlimit(2) system call may
be used to determine the maximum permissible size of the data segment. It
will not be possible to set the break beyond
rlim.rlim_max” where the
rlim.rlim_max value is returned from a call to
&rlim). (See end(3) for the
definition of etext).
brk() function returns the
value 0 if successful; otherwise the value -1 is returned and
the global variable errno is set to indicate the
sbrk() function returns the prior
break value if successful; otherwise the value (void
*)-1 is returned and the global variable errno
is set to indicate the error.
sbrk() functions will fail if:
brk() function appeared in
Version 7 AT&T UNIX.
FreeBSD 11.0 introduced the arm64 and riscv
architectures which do not support
Setting the break may fail due to a temporary lack of swap space. It is not possible to distinguish this from a failure caused by exceeding the maximum size of the data segment without consulting getrlimit(2).
sbrk() is sometimes used to monitor heap
use by calling with an argument of 0. The result is unlikely to reflect
actual utilization in combination with an mmap(2) based
are not thread-safe.
|June 2, 2018||Debian|