views:

85

answers:

3

Hi all,

Most architectures have a memory map where the user application grows towards lower memory where the stack grows to the opposite direction. I am wondering what is happening when I write such a big C-program that all the space for the application and the is taken away, ie, that stack pointer and application try to write to the same region in memory? I assume in C something like a segmentation fault occurs? Is there any processor support that tries to avoid such a problem from happening?

Thanks

+1  A: 

No, in C you can get out of memory, which you only notice directly if you actually check the return value of malloc et al. If not, you probably get to dereference a null pointer somewhere, making your app crash. But possibly there may be no immediate visible signs, only your memory gets silently corrupted. Since the memory space for the application is managed by the app itself, the processor/OS can't detect such errors. In modern OSs memory space of the OS itself and of other apps is protected from your app, so if you accidentally try to write to memory outside your own memory space, you are likely to get segmentation fault. But inside your own memory space, it is up to yourself to protect your memory.

Péter Török
+1  A: 

The stack pointer is limited. Once it tries to go further than allowed, you typically get a StackOverflow exception or interrupt, leading to program termination. This most commonly happens with runaway recursive functions.

Similarly, space for the stack is reserved, and not accessible to the heap allocator. When you try to do a heap allocation (malloc or new) without enough space, the allocator will typically return NULL or throw an OutOfMemory exception.

I disagree with the answer that says "there will be no immediate visible signs, only your memory gets silently corrupted."

You'll either get a StackOverflow or OutOfMemory, depending on which resource was exhausted first.

abelenky
I think unless you are specifically looking for exceptions, you will just segfault/segv at some point when you try to access memory after filling it all...
Aaron H.
Aaron: There won't be any memory corruption, as writing to the null pointer (or a small offset from it) will fail without corrupting memory, and trying to perform a call past the end of the stack will fail cleanly as well: the state of your program will be valid when the OS exception/signal happens and you are guaranteed to be able to recover.
BCoates
@bcoats, I wasn't saying there would be, I was just pointing out that you wouldn't actually have an "exception" in C, i.e. no throw. It wasn't a terribly important point...
Aaron H.
+1  A: 

Abelenky is correct, modern architectures will trap the stack growing past some limit much smaller than all available address space (this is easy to test with a simple recursive function)

Also, "App grows down, stack grows up" doesn't really describe the memory mapping of multithreaded systems anyway, each thread has it's own stack, which has a pre-set maximium size, and the heap is one or more seperately mapped areas of address space.

The easiest way to figure this stuff out is to attach a debugger to a simple test program; you can see the memory regions used by your process in any decent one. be sure to look where your libraries and code are loaded, as well as more than one thread worth of stack.

BCoates