From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: stack overflow Date: Thu, 14 Feb 2008 09:48:15 +0100 Message-ID: <871w7fore8.fsf@gnu.org> References: <47B2A8DF.9070004@tammer.net> <87tzkd8bvz.fsf@gnu.org> <87ejbh8ben.fsf@gnu.org> <47B2D88F.1040505@tammer.net> <87ir0tvx6e.fsf@inria.fr> <87wsp83807.fsf@ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1202979027 10942 80.91.229.12 (14 Feb 2008 08:50:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Feb 2008 08:50:27 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Feb 14 09:50:50 2008 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JPZne-0005c2-4q for guile-devel@m.gmane.org; Thu, 14 Feb 2008 09:50:34 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JPZnA-0001d7-93 for guile-devel@m.gmane.org; Thu, 14 Feb 2008 03:50:04 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JPZlm-0001Ef-Hn for guile-devel@gnu.org; Thu, 14 Feb 2008 03:48:38 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JPZlh-0001Cr-My for guile-devel@gnu.org; Thu, 14 Feb 2008 03:48:37 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JPZlg-0001CY-PL for guile-devel@gnu.org; Thu, 14 Feb 2008 03:48:32 -0500 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JPZlg-0001Fg-6p for guile-devel@gnu.org; Thu, 14 Feb 2008 03:48:32 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JPZla-0000GJ-5V for guile-devel@gnu.org; Thu, 14 Feb 2008 08:48:26 +0000 Original-Received: from 193.50.110.102 ([193.50.110.102]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Feb 2008 08:48:26 +0000 Original-Received: from ludo by 193.50.110.102 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Feb 2008 08:48:26 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 44 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 193.50.110.102 X-Revolutionary-Date: 26 =?iso-8859-1?Q?Pluvi=F4se?= an 216 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEB1F5364 X-PGP-Key: http://www.laas.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: i686-pc-linux-gnu User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Cancel-Lock: sha1:jAmtok+LsUAHeOv+gc4OIIVbZ5s= X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:7002 Archived-At: Hi, Neil Jerram 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.