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 _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
