Browse thread
Native code stack overflow detection guarantees
-
Michael Ekstrand
-
Mark Shinwell
- Mark Shinwell
- Goswin von Brederlow
-
Mark Shinwell
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2010-07-09 (08:46) |
From: | Mark Shinwell <mshinwell@j...> |
Subject: | Re: [Caml-list] Native code stack overflow detection guarantees - followup |
On Fri, Jul 09, 2010 at 09:39:06AM +0100, Mark Shinwell wrote: > On Thu, Jul 08, 2010 at 08:59:30PM -0400, Michael Ekstrand wrote: > > Therefore, I am wondering: are there documented guarantees on which the > > native code stack overflow behavior rests? Linux processes usually receive > > a segmentation fault when they run out of stack space; is that guaranteed, > > or is it simply the usual convenient behavior? What about for other > > systems? > > I am not an expert on all the various cases which might arise during a case > of stack overflow, but I believe on Linux it is exposed to userland as a > segmentation fault. Exactly how this is exposed shouldn't be any different > when executing Caml native-compiled code or C code, for example. In terms of > Caml-specific behaviour (and assuming that the user's code does not itself > alter the signal handling behaviour) then the runtime should catch the stack > overflow via the SIGSEGV handler. The intuition behind what is supposed to > happen next is as follows: if the faulting address was in the stack, and the > program counter (PC) was "in your Caml program", then we produce a > Stack_overflow exception. Otherwise we will just invoke the default signal > action for the segmentation fault, which on Linux will terminate the program. > > (There are lots of functions in the runtime which could cause a stack > overflow in the case of a bug in their own code; and it would probably be bad > if those ended up with a Stack_overflow exception rather than a segfault. > This seems to me to be at least one reason why you probably don't want to > turn every segfault in the stack into a Stack_overflow exception; instead, we > try to distinguish based on the PC.) I should add that what I wrote was for Linux/x86. On other platforms the behaviour may differ depending on what system support is available. You need HAS_STACK_OVERFLOW_DETECTION (see the Caml configure script) set to get any of this at all; and to have the distinguishing based on the program counter location, you need CONTEXT_PC to have been defined (see asmrun/signals_osdep.h in the Caml source). Mark