# Problem in memory allocation

This is a discussion on Problem in memory allocation within the C Programming forums, part of the General Programming Boards category; I want to allocate 512 B of memory for each partition. I have done the following code, i am getting ...

1. ## 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]);
}```

2. 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

3. i agree with matsp but i wish to know how you were able to conclude that 520 bytes of memory was allocated ...

4. 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. is it debug or release build?

6. Just for example I am doing this prog

7. Originally Posted by sarathius
Just for example I am doing this prog
So for example you compiling it as Release or Debug?

8. 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