程序的堆内存的初始大小

Question

Program:

#include<stdio.h>
#include<sys/types.h>
#include<malloc.h>
main()
{
    int *i1, *i2;
    char *s;
    printf("sbrk(0) before malloc(4): %x\n", sbrk(0));
    i1 = (int *) malloc(sizeof(int));
    printf("sbrk(0) after `i1 = (int *) malloc(4)': %x\n", sbrk(0));
    i2 = (int *) malloc(sizeof(int));
    printf("sbrk(0) after `i2 = (int *) malloc(4)': %x\n", sbrk(0));
}

Output:

sbrk(0) before malloc(4): a027000
sbrk(0) after `i1 = (int *) malloc(4)': a048000
sbrk(0) after `i2 = (int *) malloc(4)': a048000

what is the initial size of the heap memory for the above program. I think, at the initial stage of the program, the starting and ending address of the heap are same. Once, we call the malloc, it allocate memory using sbrk.

The above program shows that, at first sbrk(0) returns a027000 as program break. After the malloc statement is executed, the program break is changed to a048000. It shows that, before calling malloc, the heap does not have enough memory. So, only the program break is changed after calling malloc. At initial state, if the heap had the enough memory, there is no need to change the program break. So at first, the size of heap is zero. Is it right?

Answer 1

What happens depends on what your O/S does before your main() is called.

On Mac OS X, there's a huge amount of memory allocation that occurs before your main() function gets called. I currently have a list of 18 or so suppressed 'memory abuses' that are all from things that happen before the system-provided startup code calls main() .

Running a simple program that prints its arguments one per line, but giving it no arguments so there is no output, yields a usage report from valgrind like this:

==59405== Memcheck, a memory error detector
==59405== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==59405== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==59405== Command: /Users/jleffler/bin/al
==59405== 
--59405-- /Users/jleffler/bin/al:
--59405-- dSYM directory is missing; consider using --dsymutil=yes
--59405-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
--59405-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times)
--59405-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times)
==59405== 
==59405== HEAP SUMMARY:
==59405==     in use at exit: 34,808 bytes in 417 blocks
==59405==   total heap usage: 517 allocs, 100 frees, 41,784 bytes allocated
==59405== 
==59405== LEAK SUMMARY:
==59405==    definitely lost: 16 bytes in 1 blocks
==59405==    indirectly lost: 0 bytes in 0 blocks
==59405==      possibly lost: 13,002 bytes in 109 blocks
==59405==    still reachable: 21,790 bytes in 307 blocks
==59405==         suppressed: 0 bytes in 0 blocks
==59405== Rerun with --leak-check=full to see details of leaked memory
==59405== 
==59405== For counts of detected and suppressed errors, rerun with: -v
==59405== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

The code for the program?

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv)  
{ 
    if (argc > 1)
    {
        while (*++argv) 
            puts(*argv);
    }
    return(EXIT_SUCCESS); 
}

Lots of memory activity, but none of it in the code I wrote. The leak is one of a number that I have documented in a suppressions file.

Answer 2

When glibc debuginfo is installed (eg on Fedora 22: dnf debuginfo-install glibc-2.21-5.fc22.x86_64 ) one can print out the main_arena and mp_ .

Debugging a program with an empty int main(void) :

mp_.sbrk_base is the base of the heap. On my Linux when main was called heap doesn't exist. After calling malloc(1000) mp_.sbrk_base is 0x602000 . main_arena.top is the free memory chunk at the top of heap. It is 0x6023f0

(gdb) b main
Breakpoint 1 at 0x4004fa: file test.c, line 3.
(gdb) r 
Starting program: /home/m/a.out 

Breakpoint 1, main () at test.c:3
3       return 0;
(gdb) p mp_
$1 = {trim_threshold = 131072, top_pad = 131072, mmap_threshold = 131072, arena_test = 8, arena_max = 0, n_mmaps = 0, 
  n_mmaps_max = 65536, max_n_mmaps = 0, no_dyn_threshold = 0, mmapped_mem = 0, max_mmapped_mem = 0, max_total_mem = 0, 
  sbrk_base = 0x0}
(gdb) p main_arena 
$2 = {mutex = 0, flags = 0, fastbinsY = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, top = 0x0, 
  last_remainder = 0x0, bins = {0x0 <repeats 254 times>}, binmap = {0, 0, 0, 0}, next = 0x7ffff7dd6b20 <main_arena>, 
  next_free = 0x0, system_mem = 0, max_system_mem = 0}
(gdb) call malloc(1000)
$3 = (void *) 0x602010
(gdb) p mp_
$4 = {trim_threshold = 131072, top_pad = 131072, mmap_threshold = 131072, arena_test = 8, arena_max = 0, n_mmaps = 0, 
  n_mmaps_max = 65536, max_n_mmaps = 0, no_dyn_threshold = 0, mmapped_mem = 0, max_mmapped_mem = 0, max_total_mem = 0, 
  sbrk_base = 0x602000 ""}
    (gdb) p main_arena
$5 = {mutex = 0, flags = 1, fastbinsY = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, top = 0x6023f0, 
  last_remainder = 0x0, bins = {0x7ffff7dd6b78 <main_arena+88>, 0x7ffff7dd6b78 <main_arena+88>, [...]
0x7ffff7dd7198 <main_arena+1656>, 0x7ffff7dd71a8 <main_arena+1672>, 0x7ffff7dd71a8 <main_arena+1672>...}, binmap = {0, 
0, 0, 0}, next = 0x7ffff7dd6b20 <main_arena>, next_free = 0x0, system_mem = 135168, max_system_mem = 135168}

(gdb) call sbrk(0)
$6 = 6434816
(gdb) p (void*)$6
$7 = (void *) 0x623000
(gdb)