[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
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
- Avoid C stack overflow, Dmitry Antipov, 2014/03/13
- Re: Avoid C stack overflow, Eli Zaretskii, 2014/03/13
- Re: Avoid C stack overflow, Paul Eggert, 2014/03/13
- Re: Avoid C stack overflow, Eli Zaretskii, 2014/03/13
- Re: Avoid C stack overflow,
Dmitry Antipov <=
- Re: Avoid C stack overflow, Paul Eggert, 2014/03/14
- Re: Avoid C stack overflow, Dmitry Antipov, 2014/03/14
- Re: Avoid C stack overflow, Stefan Monnier, 2014/03/14
- Re: Avoid C stack overflow, Paul Eggert, 2014/03/14
- Re: Avoid C stack overflow, Stefan, 2014/03/14
- Re: Avoid C stack overflow, Stephen J. Turnbull, 2014/03/14