Re: Avoid C stack overflow

[Dmitry Antipov]

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 
situations."

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).

Dmitry