0

Can this "overrun" condition ever occur? Or, the system guarantees that the stack and heap are two completely isolated areas in the process's virtual address space, so that access/manipulation done in the stack can never affect the heap and vice versa?

One specific scenario that I'd like to find out is whether it's possible for the process to corrupt its memory in such a way that causes the system to no longer correctly manage the stack or heap.

Here is a useful link I've found: What and where are the stack and heap?

trincot
  • 317,000
  • 35
  • 244
  • 286
Ltf4an
  • 787
  • 5
  • 18

1 Answers1

0

I think before that would happen, the program would terminate on either a std::bad_alloc type error (heap) or a stack overflow type error (stack). The heap and stack exist separately, and the only way I could see them intersecting would be in one of the two conditions I mentioned above, either of which would cause the program responsible to crash.

dadude999
  • 306
  • 2
  • 8
  • Dadude999, thank you for the comments. I understand that the mentioned errors would cause the process to be fail. I've added a specific scenario to my post. – Ltf4an Jan 26 '14 at 17:15
  • From what I understand, UNIX allows you to set how much memory an individual process can use, so there shouldn't be any overflow into memory not owned by that particular process. So I don't believe any kind of corruption could happen based on anything a single process does. On the other hand, if the process uses `fork()` to create new processes, it can now consume a lot more memory (see [here](https://en.wikipedia.org/wiki/Fork_bomb)). That can also be guarded against by limiting how much virtual memory a single user on your system may use. – dadude999 Jan 26 '14 at 23:45
  • Granted, you can get [buffer overflows](https://en.wikipedia.org/wiki/Buffer_overflow), but that shouldn't cause the system to lose the ability to modify that memory. And as I mentioned, generally those situations should cause the program to simply get a `SIGSEGV` and exit. – dadude999 Jan 26 '14 at 23:56
  • My scope of interest is within the same process, not concerning about its impact on other processes; nevertheless, thank you for the expansion. So, it sounds like memory corruption can only affect the behavior/correctness of the process itself; the ability of the system to manage heap and stack of a process is safely guarded, as if that ability is done within the kernel context. – Ltf4an Jan 27 '14 at 02:58