From: ludo@gnu.org (Ludovic Courtès)
To: guile-devel@gnu.org
Subject: Re: stack overflow
Date: Thu, 14 Feb 2008 09:48:15 +0100 [thread overview]
Message-ID: <871w7fore8.fsf@gnu.org> (raw)
In-Reply-To: 87wsp83807.fsf@ossau.uklinux.net
Hi,
Neil Jerram <neil@ossau.uklinux.net> writes:
> Not to disagree with anything that's already been said in this
> thread... But I wonder if there is a way to make Guile's stack
> overflow checking a bit less fragile - i.e. less subject to the
> behaviour of particular compilers / OSs / optimization options?
>
> I think all we're really trying to do, with the stack overflow
> feature, is guard against a suspected infinite recursion, without
> resorting to crashing the whole program. Perhaps there is a cunning
> way to do that without having to set an arbitrary stack depth limit?
> Any ideas would be most welcome.
A platform-independent way to achieve this would be to somehow count
Scheme stack frames (since we are concerned with stack overflows in
Scheme code). Of course, we don't want to traverse the whole Scheme
stack to determine the stack depth. So the evaluator would need to
maintain the current stack depth in an integer.
In `eval.i.c', instead of:
#ifdef EVAL_STACK_CHECKING
if (scm_stack_checking_enabled_p && SCM_STACK_OVERFLOW_P (&proc))
{
We could have something along the lines of:
#ifdef EVAL_STACK_CHECKING
if (scm_stack_checking_enabled_p)
{
scm_i_eval_stack_depth++;
if (scm_i_eval_stack_depth > SCM_STACK_LIMIT)
{
We must also change `RETURN' to do "scm_i_eval_stack_depth--".
Hopefully it's not too unreasonable performance-wise.
What do you think?
Thanks,
Ludovic.
next prev parent reply other threads:[~2008-02-14 8:48 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <47B2A8DF.9070004@tammer.net>
[not found] ` <87tzkd8bvz.fsf@gnu.org>
[not found] ` <87ejbh8ben.fsf@gnu.org>
[not found] ` <47B2D88F.1040505@tammer.net>
[not found] ` <87ir0tvx6e.fsf@inria.fr>
2008-02-13 20:40 ` stack overflow Neil Jerram
2008-02-14 8:48 ` Ludovic Courtès [this message]
2008-02-14 10:26 ` Mikael Djurfeldt
2008-02-14 11:25 ` Ludovic Courtès
2008-02-14 11:39 ` Mikael Djurfeldt
2008-02-25 21:52 ` Neil Jerram
2008-07-16 12:34 ` Ludovic Courtès
2008-09-12 20:47 ` Stack calibration Ludovic Courtès
2008-09-27 18:20 ` Neil Jerram
2008-09-28 20:05 ` Ludovic Courtès
2008-09-30 22:10 ` Neil Jerram
2008-10-02 8:25 ` Andy Wingo
2008-10-02 8:38 ` Neil Jerram
2008-10-02 22:30 ` Neil Jerram
2008-10-06 22:32 ` Ludovic Courtès
2008-10-06 23:11 ` Neil Jerram
2008-10-09 22:53 ` Neil Jerram
2008-10-10 13:22 ` Greg Troxel
2008-10-10 18:04 ` Neil Jerram
2008-10-10 18:28 ` Greg Troxel
2008-10-10 18:41 ` Neil Jerram
2008-10-11 17:22 ` Ludovic Courtès
2008-10-12 15:59 ` Neil Jerram
2008-10-12 21:16 ` Neil Jerram
2008-10-13 21:37 ` Neil Jerram
2008-10-14 7:25 ` Ludovic Courtès
2008-10-17 20:49 ` Neil Jerram
2008-10-14 7:19 ` Ludovic Courtès
2008-09-28 20:07 ` Ludovic Courtès
2008-09-30 22:11 ` Neil Jerram
2008-02-17 1:38 ` stack overflow Han-Wen Nienhuys
2008-02-17 9:20 ` Mikael Djurfeldt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871w7fore8.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).