views:

395

answers:

8

Is there a defined behavior for handling a stack overflow?

Apart from terminating the process, it doesn't seem like there's a whole lot that can be done. I'm just wondering if anyone might know what the C standard has to say about it.

+1  A: 

I'm fairly sure the specifics of what happen are defined by the operating system however, in all cases, the program should exit. You are correct in assuming that there is really nothing you can do once a stack overflow occurs (at least as a programmer). All you can really do is prevent them from happening in the first place.

Jack
+1  A: 

It's up to the operating system. Many operating systems allow the default stack size to be overwritten, though. For example, on Windows, you can use this linker flag to increase the stack size from 1MB to a higher value.

Reed Copsey
+13  A: 

The standard does not require the use of a stack, and has nothing to say about stack overflows.

anon
+4  A: 

The C standard doesn't even define a stack, so it certainly doesn't define what happens when the stack overflows.

Rob Kennedy
+2  A: 

According to some answers to this question, the C standards don't even have anything to say about the existence of a stack, let alone a stack overflow.

Alnitak
+8  A: 

The C99 standard doesn't define a stack; it only discusses automatic or allocated storage in the abstract, whereas a contiguous stack with overflow detection is only one mechanism for implementing automatic storage.

Section 7.14 of the standard defines SIGSEGV as the signal which occurs on "an invalid access to storage". Implementations of C are not required to generate any signals, but implementations using a contiguous fixed size stack* typically signal SIGSEGV if a stack overflow is detected.

You can register a signal handler function for SIGSEGV, but it can't return - "[i]f and when the function returns, if the value of sig is SIGFPE, SIGILL, SIGSEGV, or any other implementation-defined value corresponding to a computational exception, the behavio[u]r is undefined".

(* not that I've knowingly worked with C implementations which don't, but I'm not aware of anything in the C standard preventing the use of common techniques used to implement growable automatic storage domains in other environments)

Pete Kirkham
+1  A: 

As other people have mentioned, the standard does not say anything about a stack.

But, I think it it were to define stack overflow behavior, the standard would say it results in undefined behavior.

::rimshot::

Michael Burr
+4  A: 

The answers here are correct in stating that it is nothing to do with the c standard but your statement that "Apart from terminating the process, it doesn't seem like there's a whole lot that can be done" is not - as a generality - true.

In fact, on most systems with virtual memory management and on demand paging, the allocated stack is quite small (typically 4KB more than is currently being used) and often overflows (which generates a page fault interrupt) and the OS simply adds another page of memory to the stack for the thread.

The stack limit of - typically - 1MB, is just a fairly arbitrary figure chosen to guard against runaway programs and generally isn't an absolute limit (though it was on some memory models with intel processors IIRC). It would generally not make sense to allocate 1MB of physical memory to each thread.

Dipstick