We run the malloc_brk_test program with no parameters, that is, using the defaults:
$ ./malloc_brk_test init_brk = 0x1c97000 #: malloc( n) = heap_ptr cur_brk delta [cur_brk-init_brk] 0: malloc( 8) = 0x1c97670 0x1cb8000 [135168] 1: malloc( 4083) = 0x1c97690 0x1cb8000 [135168] 2: malloc( 3) = 0x1c98690 0x1cb8000 [135168]$
The process prints out its initial program break value: 0x1c97000. It then allocates just 8 bytes (via the malloc(3) API); under the hood, the glibc allocation engine invokes the sbrk(2) system call to grow the heap; the new break is now 0x1cb8000, an increase of 135,168 bytes = 132 KB from the previous break (clearly seen in the delta column in the preceding code)!
Why? Optimization: glibc ...
