C: sbrk() addresses ascending or descending? - c

Question

When sbrk() returns a pointer to an address that is the beginning of the heap, are the addresses ascending or descending? For example, if I had a 10 byte heap from addresses 1 to 10, would sbrk() return a pointer to address 10 or 1?
On a similar note, heap addresses tend to grow "down"... but how can I figure out whether the addresses increase or decrease on my computer?

Answer 1

The man page on Mac OS X says:
The brk and sbrk functions are historical curiosities left over from earlier days before the
advent of virtual memory management.
The current value of the program break is reliably returned by sbrk(0).
The sbrk function returns a pointer to the base of the
new storage if successful; otherwise -1 with errno set to indicate why the allocation failed.
Suppose you use:
void *base = sbrk(1024);
After that, assuming no error, base will contain the starting address of a 1024 byte (minimum) block of memory; (char *)base + 1024 will be beyond what you requested, though it may still be valid since the page size may be larger than 1024.
It doesn't say directly whether a subsequent allocation will have a larger or smaller address than another. However, it is likely to be in increasing order of addresses.
The brk() function sets the break or lowest address of a
process's data segment (uninitialized data) to addr (immediately above bss). Data addressing
is restricted between addr and the lowest stack pointer to the stack segment. Memory is allocated by brk in page size pieces; if addr is not evenly divisible by the system page size, it
is increased to the next page boundary.
This implies that the extra space is after the data and bss segments, and grows up towards the stack (which grows downwards in memory). However, relying on that would probably be foolhardy. You'd do best to use sbrk(0) to establish the current end after calling sbrk(extra) to get extra space; this will tell you what you really got and the two addresses tell you where it was made available.

Answer 2

If you are on Linux, you can examine /proc/$PID/maps to see how the virtual address space is utilized for each process.
Sample code: mappingTest.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int foo(int depth) {
char buf[8192];
if (0 == depth)
printf("%p\n", buf);
if (1000 < depth) {
printf("%p\n", buf);
return getchar();
} else {
return 1 + foo(depth + 1);
}
}
int main() {
const size_t SIZE = 1000 * 1000 * 1000;
getchar();
char * const p = malloc(SIZE);
printf("%p\n", p);
getchar();
free(p);
getchar();
foo(0);
return 0;
}
Note: char buf[8192] and recursion of 1000 times assume that the maximum stack size is 8 MB (you can confirm with ulimit -s.)
$ gcc mappingTest.c -o mappingTest -Wall -Wextra -Wno-missing-field-initializers -std=c89 -O0 -g3 && echo OK
OK
$ ./mappingTest
At the 1st getchar(), we see the following memory mappings for the process:
$ cat /proc/`pidof mappingTest`/maps
00400000-00401000 r-xp 00000000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
00600000-00601000 r--p 00000000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
00601000-00602000 rw-p 00001000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
7f2e96e8a000-7f2e9703f000 r-xp 00000000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e9703f000-7f2e9723f000 ---p 001b5000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e9723f000-7f2e97243000 r--p 001b5000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e97243000-7f2e97245000 rw-p 001b9000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e97245000-7f2e9724a000 rw-p 00000000 00:00 0
7f2e9724a000-7f2e9726c000 r-xp 00000000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7f2e97443000-7f2e97446000 rw-p 00000000 00:00 0
7f2e97469000-7f2e9746c000 rw-p 00000000 00:00 0
7f2e9746c000-7f2e9746d000 r--p 00022000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7f2e9746d000-7f2e9746f000 rw-p 00023000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7fffa6d43000-7fffa6d64000 rw-p 00000000 00:00 0 [stack]
7fffa6dff000-7fffa6e00000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
We hit Enter and proceed to the 2nd getchar().
I got 0x7f2e5b4dd010 on my terminal as the value of p and it falls within the first anonymous mapping region 7f2e5b4dd000-7f2e96e8a000 in the below listing, but it didin't exist in the above listing.
$ cat /proc/`pidof mappingTest`/maps
00400000-00401000 r-xp 00000000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
00600000-00601000 r--p 00000000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
00601000-00602000 rw-p 00001000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
7f2e5b4dd000-7f2e96e8a000 rw-p 00000000 00:00 0
7f2e96e8a000-7f2e9703f000 r-xp 00000000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e9703f000-7f2e9723f000 ---p 001b5000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e9723f000-7f2e97243000 r--p 001b5000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e97243000-7f2e97245000 rw-p 001b9000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e97245000-7f2e9724a000 rw-p 00000000 00:00 0
7f2e9724a000-7f2e9726c000 r-xp 00000000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7f2e97443000-7f2e97446000 rw-p 00000000 00:00 0
7f2e97468000-7f2e9746c000 rw-p 00000000 00:00 0
7f2e9746c000-7f2e9746d000 r--p 00022000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7f2e9746d000-7f2e9746f000 rw-p 00023000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7fffa6d43000-7fffa6d64000 rw-p 00000000 00:00 0 [stack]
7fffa6dff000-7fffa6e00000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
We hit Enter and proceed to the 3rd getchar().
In the below listing, we see the anonymous mapping region disappeared due to free().
$ cat /proc/`pidof mappingTest`/maps
00400000-00401000 r-xp 00000000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
00600000-00601000 r--p 00000000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
00601000-00602000 rw-p 00001000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
7f2e96e8a000-7f2e9703f000 r-xp 00000000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e9703f000-7f2e9723f000 ---p 001b5000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e9723f000-7f2e97243000 r--p 001b5000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e97243000-7f2e97245000 rw-p 001b9000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e97245000-7f2e9724a000 rw-p 00000000 00:00 0
7f2e9724a000-7f2e9726c000 r-xp 00000000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7f2e97443000-7f2e97446000 rw-p 00000000 00:00 0
7f2e97468000-7f2e9746c000 rw-p 00000000 00:00 0
7f2e9746c000-7f2e9746d000 r--p 00022000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7f2e9746d000-7f2e9746f000 rw-p 00023000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7fffa6d43000-7fffa6d64000 rw-p 00000000 00:00 0 [stack]
7fffa6dff000-7fffa6e00000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
We hit Enter and proceed to the 4th getchar() in the deeply nested calls of foo().
I got 0x7fffa6d60ba0 and 0x7fffa6582ff0 on my terminal as the addresses of buf in the 1st and 1001st recursive call of foo(). Both of them fall within the [stack] region (7fffa6582000-7fffa6d64000; 0x7e2000 == 8 MB) now. But note that it was previously 7fffa6d43000-7fffa6d64000; 0x21000 == 132 KB.
$ cat /proc/`pidof mappingTest`/maps
00400000-00401000 r-xp 00000000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
00600000-00601000 r--p 00000000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
00601000-00602000 rw-p 00001000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
7f2e96e8a000-7f2e9703f000 r-xp 00000000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e9703f000-7f2e9723f000 ---p 001b5000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e9723f000-7f2e97243000 r--p 001b5000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e97243000-7f2e97245000 rw-p 001b9000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e97245000-7f2e9724a000 rw-p 00000000 00:00 0
7f2e9724a000-7f2e9726c000 r-xp 00000000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7f2e97443000-7f2e97446000 rw-p 00000000 00:00 0
7f2e97468000-7f2e9746c000 rw-p 00000000 00:00 0
7f2e9746c000-7f2e9746d000 r--p 00022000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7f2e9746d000-7f2e9746f000 rw-p 00023000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7fffa6582000-7fffa6d64000 rw-p 00000000 00:00 0 [stack]
7fffa6dff000-7fffa6e00000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
You may have more fun with inline assembly like this:
#define PEEK_ESP(reg) \
__asm__ __volatile__ ( \
"movq %%rsp, %0" \
: "=r"(reg) \
)
...
void *p;
PEEK_ESP(p);