Thread: checking programm break with sbrk

  1. #1
    Registered User
    Join Date
    Mar 2017
    Posts
    2

    Post checking programm break with sbrk

    I've written this code :

    Code:
        #define MAX_ALLOC 1000000
        int number = 1;
        void *ptr = NULL;
    
        if (argc != 2){
            controlled_exit( "you have to give 1 argument" );
        }
    
    
        if ( ( number = strtol( argv[1], NULL, 10 ) ) == 0 ){
            controlled_exit("the argument must be over 0 and not a character");
        }
        else if ( number > MAX_ALLOC || number < 0 ){
            controlled_exit("the argument must be over 0 and 1000000 or less");
        }
    
        printf("Program break: %p\n", sbrk(0));
    
        if ( ( ptr = malloc(number) ) == NULL)
                    errxit("malloc");
    
        printf("Program break (after malloc): %p\n", sbrk(0));
    
        free(ptr);
    
        printf("Program break (after free): %p\n", sbrk(0));
    
        return EXIT_SUCCESS;
    In the output, the program break before and after free(ptr) is the same. Did I do something wrong (In my book it says, after releasing a block on the top of the heap, the Program break will lower, when the free block at the top is large enough) or is one million bytes too small?

  2. #2
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,659
    The C runtime library is very lazy about giving memory back to the OS.

    There is no point giving small bits of memory back to the OS, only to waste even more time getting the memory back again at the next malloc call.

    > or is one million bytes too small?
    Quite possibly.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  3. #3
    Registered User
    Join Date
    Jun 2015
    Posts
    1,640
    Malloc is fairly intelligent. Your program just allocated a large chunk of memory, and then freed it. As far as malloc is concerned, there's every reason to believe that you will be mallocing memory again. The last thing it wants is to constantly return the memory to the system (with a system call) and then ask for it back again (with another system call).

    And remember that the memory is virtual anyway, so it's not like the actual ram is unavailable to other programs.

    And considering that the memory is totally new to your process and you don't actually write anything to it, it's probably not even backed up by any real storage of any kind and it costs absolutely nothing to keep it. You should try writing something to all that memory to see if it makes a difference.

    Also, sbrk is not necessarily the best way to see what's happening with malloc. GNU malloc uses multiple "arenas", each potentially containing mulitple "heaps", and can mmap memory, too, which will not necessarily affect the program break (except perhaps for bookkeeping).

    You should save the initial and final program breaks and print the difference to see if it's at least as big as the memory you asked for.

    Also, there are extra malloc control functions in malloc.h, such as malloc_trim and mallopt, malloc_info.

    gnu malloc

    Malloc Internals

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. a programm plz help me!!!!
    By chaudhryali55 in forum C++ Programming
    Replies: 1
    Last Post: 11-21-2009, 07:29 AM
  2. Is there something like break(2) (multiple break) ?
    By Phuzzillogic in forum C++ Programming
    Replies: 11
    Last Post: 05-11-2009, 04:05 AM
  3. Plz help me C programm
    By ferroz1 in forum C Programming
    Replies: 7
    Last Post: 05-10-2008, 06:55 AM
  4. Question on sbrk()!!!!!!!!!!!!!!help!!!!!!!
    By SweeLeen in forum Linux Programming
    Replies: 1
    Last Post: 02-16-2006, 02:13 AM
  5. Help on sbrk()
    By kakashi in forum Linux Programming
    Replies: 1
    Last Post: 02-13-2006, 03:39 AM

Tags for this Thread