[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Avoid C stack overflow

From: Dmitry Antipov
Subject: Re: Avoid C stack overflow
Date: Fri, 14 Mar 2014 09:47:39 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

On 03/13/2014 09:57 PM, Paul Eggert wrote:

Don't most systems solve the problem with guard pages these days? If so, Emacs 
should just rely on these pages,
as that shouldn't require slowing down Ffuncall etc. And if not, if memory 
management is
available Emacs could install a guard page of its own, again without slowing 
down the main interpreter loop.

From GCC manual:

"For most operating systems, gcc does not perform stack overflow checking by 
default. This means that if the main
environment task or some other task exceeds the available stack space, then 
unpredictable behavior will occur. Most
native systems offer some level of protection by adding a guard page at the end 
of each task stack. This mechanism
is usually not enough for dealing properly with stack overflow situations 
because a large local variable could “jump”
above the guard page. Furthermore, when the guard page is hit, there may not be 
any space left on the stack for
executing the exception propagation code. Enabling stack checking avoids such 

I.e. GCC developers suggests do not rely on guard pages and use -fstack-check.

Also, the code as given won't work on systems that have split stacks (e.g., gcc 
-fsplit-stack), and would need
to be ported to them.

From alloc.c:

  /* This assumes that the stack is a contiguous region in memory.  If
     that's not the case, something has to be done here to iterate
     over the stack segments.  */
  mark_memory (stack_base, end);

I.e. -fsplit-stack is incompatible with our current GC (if GC_MARK_STACK, which 
is the default
for most (all?) supported configurations).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]