From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id D2245BC57 for ; Fri, 9 Jul 2010 10:46:31 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwBAGt+Nkwmachzl2dsb2JhbACgOBUBAQEBAQgVBzO+MIUnBIp6 X-IronPort-AV: E=Sophos;i="4.53,562,1272837600"; d="scan'208";a="66079531" Received: from mx2.janestreet.com ([38.105.200.115]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jul 2010 10:46:31 +0200 Received: from nyc-qsv-mail1.delacy.com ([172.25.22.57]) by mx2.janestreet.com with esmtp (Exim 4.71) (envelope-from ) id 1OX9E5-0005db-Gy for caml-list@inria.fr; Fri, 09 Jul 2010 04:46:29 -0400 Received: from nyc-qsv-004.delacy.com ([172.25.22.194] helo=qsmtp.delacy.com) by nyc-qsv-mail1.delacy.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71) (envelope-from ) id 1OX9E5-0001ba-FD; Fri, 09 Jul 2010 04:46:29 -0400 Received: from ldn-qws-r01.delacy.com ([172.23.65.101] helo=ldn-qws-r01) by qsmtp.delacy.com with smtp (Exim 4.71) (envelope-from ) id 1OX9E3-000666-Hm; Fri, 09 Jul 2010 04:46:29 -0400 Received: by ldn-qws-r01 (sSMTP sendmail emulation); Fri, 9 Jul 2010 09:46:26 +0100 From: "Mark Shinwell" Date: Fri, 9 Jul 2010 09:46:26 +0100 To: Michael Ekstrand Cc: caml-list@inria.fr Subject: Re: [Caml-list] Native code stack overflow detection guarantees - followup Message-ID: <20100709084626.GR29068@janestreet.com> References: <20100709083906.GQ29068@janestreet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100709083906.GQ29068@janestreet.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam: no; 0.00; shinwell:01 followup:01 0100,:01 shinwell:01 userland:01 runtime:01 runtime:01 bug:01 segfault:01 segfault:01 asmrun:01 invoke:01 wrote:01 wrote:01 stack:01 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