Dasso wrote
Can we say that a 'stack overflow' error is a 'memory leak' error, the kind that crashes program on windows machine (or other OS) ?
Normally they mean different things. You already know about the stack overflow. In "real life" it is caused mostly by the code the programmer wrote, rather than a compiler bug. Most often it's due to a very deep or even endless recursion.
Memory leak happens when you allocate heap memory (think new Something() in Jack) and then forget to release it even when it's no longer used. If this happens in a function which is called often enough, the program may run out of memory and stop working. One cause for this is when functions "forget" to release internal resource before they end.
Another, and harder to fix one, is when it's hard to track who is the "owner" of this memory. That is, who is supposed to free it. Let's say A, B and C are functions. A calls B, B calls C, C produces some result in a newly allocated block (e.g. some string) and returns it to B. Now B is the owner of this block. Depending on some condition, B may pass this block to A as a return value, or it may just return another value. In the second case, B should also release the block, but the programmer may forget to do so.
What makes it harder is, that languages like C, C++ and Jack don't indicate who is the owner of the memory. This is something that the programmers have to take care of. In large programs, these kind of problems are almost inevitable to occur and are quite hard to find and fix.
There are other types of memory related problems as well. For example in languages like C and Jack you can "forget" that you freed the memory and still try to use it afterwards. This may even work OK in some situations, like if you're using it before the system allocated it for something else. You'll still be able to read the old data that can make your problem much harder to find.
Another type is buffer overflow, where you allocate an array (the buffer) where you want to put some kind of input, be it from the keyboard, of from file or network traffic. But you don't properly handle if the input is larger than the allocated buffer and write past it. This kind of bugs are very useful to gain arbitrary code execution and even admin rights.
A different type of problem is memory fragmentation. This normally happens when a program runs for a long time. It allocates and frees chunks of memory with different sizes. And let's say it has no memory leaks. It can still run into problems, because the free memory is not in large continuous chunks, but rather in many small ones. When the program needs a new chunk of memory the allocation function may not be able to find suitable hunk of free memory, even though there is enough of it.
Even if it can find it, the time it takes to do so, can start to rise over time and make the program run slower and slower.
Many of these problems can be fixed or at least greatly reduced by using higher level languages with automatic memory management (aka garbage collectors). They have different kinds of problems though, so, as is often the case, it's about trade-offs.
Locked
