Menu
Stack is accessed through a last-in, first-out (LIFO) memory allocation system. Heap Space exists as long as the application runs and is larger than Stack, which is temporary, but faster.
Your heap will get full. When this happens, malloc() won't be able to allocate memory anymore and it's going to return NULL pointers indefinitely.
Whenever a method is invoked, a new block is created in the stack memory for the method to hold local primitive values and reference to other objects in the method. As soon as the method ends, the block becomes unused and becomes available for the next method. Stack memory size is very less compared to Heap memory.
Because the data is added and removed in a last-in-first-out manner, stack-based memory allocation is very simple and typically much faster than heap-based memory allocation (also known as dynamic memory allocation) e.g. C's malloc .
I'm currently using gdb to see the effects of low level code. Right now I'm doing the following:
int* pointer = (int*)calloc(1, sizeof(int));
yet when I examine the memory using info proc mappings in gdb, I see the following after what I presume is the .text section (since Objfile shows the name of the binary I'm debugging):
...
Start Addr End Addr Size Offset Objfile
0x602000 0x623000 0x21000 0x0 [heap]
How come the heap is that big when all I did was allocating space for a single int?
The weirdest thing is, even when I'm doing calloc(1000, sizeof(int)) the size of the heap remains the same.
PS: I'm running Ubuntu 14.04 on an x86_64 machine. I'm compiling the source using g++ (yes, I know I shouldn't use calloc in C++, this is just a test).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With