What is a stack for?
Each program consists of functions / routines / no matter which one your choice language chooses. Almost always, these functions have some local state. Even in a simple loop, you need to track the loop counter somewhere, right? It must be stored somewhere in memory.
The thing about functions is that the other thing they almost always do is call other functions. These other functions have their own local state - their local variables. You do not want your local variables to interfere with the locals of your caller. Another thing that should happen is that when FunctionA calls FunctionB and then does something else, you want the local variables in FunctionA to still be there and have the same values when FunctionB was executed.
Keeping track of these local variables is what the stack is for. Each function call is made by setting what is called a stack frame. The stack frame usually includes the return address of the caller (to complete the function), values for any method parameters and storage for any local variables.
When the second function is called, a new stack stack is created, placed on the top of the stack, and a call is made. A new feature can successfully work on the stack. When this second function returns, its stack stack is pushed out (removed from the stack), and the caller’s frame returns to its place, as before.
So to the stack. So what a bunch? He got a similar use - a place to store data. However, often there is a need for data that lives longer than one stack of the stack. It cannot go onto the stack, because when the function call returns, it drains the frame and clears - your data goes there. So you put it on a bunch. A heap is basically an unstructured chunk of memory. You request x the number of bytes, and get it, and then you can participate in it. In C / C ++, heap memory remains allocated until you explicitly release it. In garbage collections (Java / C # / Python / etc.), The heap of memory will be freed when objects on it are no longer used.
To solve your specific questions from above:
What is the difference between stack overflow and buffer overflow?
They both work with memory limitations. Stack overflow is stack specific; you wrote your code (recursion is common, but not the only reason), so it has too many nested function calls, or you store a lot of large material on the stack and it runs out of room. Most OSs set a limit on the maximum size that the stack can reach, and when you click this limit, you get a stack overflow. Modern hardware can detect stack overflows, and this usually leads to your process.
Buffer overflows are slightly different. So the first question is which buffer? Well, this is a limited piece of memory. This memory may be on the heap, or it may be on the stack. But the important thing is that you have X bytes, which, as you know, you have. Then you write code that writes X + more bytes to this space. The compiler probably already used the space outside of your buffer for other things, and by writing too much, you overwritten these other things. Buffer overflows are often not immediately visible, since you do not notice them until you try to do something with another memory that has been corrupted.
Also, remember how I mentioned that return addresses are also stored on the stack? This is the source of many security issues due to buffer overflows. You have code that uses a buffer on the stack and has an overflow vulnerability. A smart hacker can structure the data that overflows the buffer to overwrite this return address, point to the code in the buffer itself and how they get the code to execute. It is unpleasant.
What happens when I initially initialize my variables in code. Are they in a code segment or in a data segment or in a heap?
I'm going to talk in terms of C / C ++ here. Assuming you have a variable declaration:
int i;
This reserves (typically) four bytes on the stack. If instead you have:
char * buffer = malloc (100);
It actually reserves two pieces of memory. The malloc call allocates 100 bytes on the heap. But you also need memory for a pointer, a buffer. This storage is, again, on the stack, and on a 32-bit machine there will be 4 bytes (a 64-bit machine will use 8 bytes).
Where are the arrays stored ... ???
It depends on how you declare them. If you execute a simple array:
char str [128];
for example, it will reserve 128 bytes on the stack. C never gets in the heap unless you explicitly ask for it by calling a selection method like malloc.
If you specified a pointer instead (for example, the buffer above), then the storage for the pointer is on the stack, the actual data for the array is on the heap.
Is it that after executing my code, everything that was in my heap is erased ... ???
I guess, yes. The OS will clear the memory used by the process after it exits. A heap is a piece of memory in your process, so the OS will clear it. Although it depends on what you mean by "clean up." The OS marks these pieces of RAM as now free, and will use them later. If you have explicit cleanup code (for example, C ++ destructors), you need to make sure that they are called, the OS will not call them.
In general, please tell me about the heap in a more simplified way than just it for malloc and alloc?
A heap, like a name, is a bunch of free bytes that you can capture at a time, do whatever you want, and then drop it to use something else. You grab a piece of bytes by calling malloc, and you drop it by calling for free.
Why would you do this? Well, there are a couple of common reasons:
You don't know how many things you need before runtime (based on user input, for example). So you dynamically allocate a bunch as you need them.
You need big data structures. On Windows, for example, the stream stack defaults to 1 Meg. If you work with large ones, for example, bitmaps, which will be a quick way to blow your stack and get a stack overflow. So, you are a heap space, which is usually much, much larger than the stack.
Code, data, stack and heap?
Not really a question, but I wanted to clarify. The "code" segment contains executable bytes for your application. Typically, code segments are read only in memory to prevent tampering. The data segment contains constants that are compiled into code - things like strings in the initializers of the code or array need to be stored somewhere, the data segment is the place where they go. Again, a data segment is usually read only.
The stack is a writable section of memory and usually has a limited size. The OS initializes the stack, and the C startup code calls your main () function for you. The heap is also a writable section of memory. It is reserved by the OS and functions as a malloc and freely controls the extraction of blocks and their return.
So this is a review. Hope this helps.