Thread: Problem in memory allocation

  1. #1
    Registered User
    Join Date
    Feb 2008
    Posts
    39

    Problem in memory allocation

    I want to allocate 512 B of memory for each partition. I have done the following code, i am getting 520 B of memory. Why it is taking 8 B of memory extra? If anyone knows answer, let me know.


    Code:
      int *array1[4];
    
      for(i=0;i<=1;i++)                       /*Memory Partitioning of 512B each*/
       {
         array1[i] = (int *)malloc(128*sizeof(int));
         printf("\npartition=%u\n",array1[i]);
       }
    thanks in advance

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    There is ABSOLUTELY no guarantee about the spacing of individual allocations from malloc() - they can be directly adjacent, have a small space between them or be completely random.

    What is almost certain is that the memory allocation has some sort of overhead to track where the allocation belongs and it's size, which is created by malloc(), and used to free the memory allocation when you call free().

    There is OFTEN an alignment as well, so if you allocate a block, it over-allocates to make the next allocation align to a certain boundary, e.g. 32 bytes.

    But as I stated above, there is nothing to guarantee what you get back from malloc(), the only guarantees given is that you have a memory block of at least the size you asked for at an address that is not NULL, and that if you can't allocate, you get NULL back.

    If you actually want to (say) allocate 4 blocks of 512 byte that are next to each other, then you're better off allocating one block of 4*512 bytes, and then splitting it up in your code.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #3
    Registered User
    Join Date
    Jan 2008
    Posts
    32
    i agree with matsp but i wish to know how you were able to conclude that 520 bytes of memory was allocated ...

  4. #4
    Registered User
    Join Date
    Feb 2008
    Posts
    39
    I am getting the address value return from malloc. so from two addresses, I conclude that it is allocating 520 B of memory.
    For eg:-
    If the address value wheni=0 is 12435600, then the address value for i=1 is 12436120. So, from this I am telling it is taking 520 B of memory

  5. #5
    Hurry Slowly vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,788
    is it debug or release build?
    All problems in computer science can be solved by another level of indirection,
    except for the problem of too many layers of indirection.
    – David J. Wheeler

  6. #6
    Registered User
    Join Date
    Feb 2008
    Posts
    39
    Just for example I am doing this prog

  7. #7
    Hurry Slowly vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,788
    Quote Originally Posted by sarathius View Post
    Just for example I am doing this prog
    So for example you compiling it as Release or Debug?
    All problems in computer science can be solved by another level of indirection,
    except for the problem of too many layers of indirection.
    – David J. Wheeler

  8. #8
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    I think what Vart is trying to imply is that in Debug setting, the runtime library may choose to add "crumble zones" to the memory allocation. Crumble zones are extra memory that is filled with a pattern to detect trivial cases of "falling over the end of the allocation".

    But even without crumble zones, it's unreasonable to expect memory allocations to not have ANY overhead - there must be some way for free to know at least how much memory was allocated, and that will take "sizeof(size_t)" bytes. There may be other information that is needed too, such as if there are multiple "chunks" in the heap that the memory needs to be returned back to a particular chunk, obviously the free function would need to know this. The easy/obvious way to maintain this type of info is by keeping it in a few bytes before the actual allocation.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Problem with linked list and shared memory
    By Sirfabius in forum C Programming
    Replies: 10
    Last Post: 11-10-2008, 04:45 PM
  2. Memory leaks problem in C -- Help please
    By Amely in forum C Programming
    Replies: 14
    Last Post: 05-21-2008, 11:16 AM
  3. Dynamic memory allocation.
    By HAssan in forum C Programming
    Replies: 3
    Last Post: 09-07-2006, 05:04 PM
  4. Understanding Memory Allocation
    By Ragsdale85 in forum C Programming
    Replies: 7
    Last Post: 10-31-2005, 08:36 AM
  5. Memory Problem - I think...
    By Unregistered in forum C Programming
    Replies: 4
    Last Post: 10-24-2001, 12:14 PM