From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Neil Jerram" Newsgroups: gmane.lisp.guile.devel Subject: Re: Stack calibration Date: Thu, 2 Oct 2008 23:30:18 +0100 Message-ID: <49dd78620810021530u8f29699x88fa8c0241105a07@mail.gmail.com> References: <47B2A8DF.9070004@tammer.net> <871w7fore8.fsf@gnu.org> <66e540fe0802140226k3cd96c46x286ac753bbb2b8b7@mail.gmail.com> <87ejbfg4pr.fsf@gnu.org> <66e540fe0802140339n2121e1d9y85fcc9f019d8be0f@mail.gmail.com> <87prukog9w.fsf@ossau.uklinux.net> <87hc8lw0q2.fsf_-_@gnu.org> <49dd78620809271120j17097ffq4da8f2b8dffd4efd@mail.gmail.com> <87abdsf337.fsf@gnu.org> <49dd78620809301510q173d1777rd26240ce40f204f0@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1222986640 10023 80.91.229.12 (2 Oct 2008 22:30:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Oct 2008 22:30:40 +0000 (UTC) Cc: guile-devel@gnu.org To: "=?ISO-8859-1?Q?Ludovic_Court=E8s?=" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Oct 03 00:31:37 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 1KlWhr-0005D2-Vf for guile-devel@m.gmane.org; Fri, 03 Oct 2008 00:31:36 +0200 Original-Received: from localhost ([127.0.0.1]:39327 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KlWgo-0002cm-Qm for guile-devel@m.gmane.org; Thu, 02 Oct 2008 18:30:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KlWgh-0002aH-Oe for guile-devel@gnu.org; Thu, 02 Oct 2008 18:30:23 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KlWgg-0002YZ-6K for guile-devel@gnu.org; Thu, 02 Oct 2008 18:30:23 -0400 Original-Received: from [199.232.76.173] (port=34135 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KlWgg-0002YL-10 for guile-devel@gnu.org; Thu, 02 Oct 2008 18:30:22 -0400 Original-Received: from wa-out-1112.google.com ([209.85.146.183]:64879) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KlWgd-0004io-Je for guile-devel@gnu.org; Thu, 02 Oct 2008 18:30:20 -0400 Original-Received: by wa-out-1112.google.com with SMTP id k40so691129wah.26 for ; Thu, 02 Oct 2008 15:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=e5x03fJ5zUTLyeOcBVVrB1kamdVEnV89jt9rOe51xg8=; b=wdYB6y75S9sLsZrWkqj2vwWAm3zaVZFLX5PKol28zxuPLEDiGuOopqyQ60OYje+oMB xAndeh6BOku17jlNsCyiI+e0201cqoEIQZQgoy3CrcOLbv+H/ymcG4PQM0ETH7fR7CP/ taRz2FwsiNE56RWThz7OE8AJZHBTGas5INw8w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=sa8BZ4YYxbcgkV1TdIp8gxILKhjHSw8DAK4UVkLOcGpYnGLVN3tNRqj9GZeNd5rdwL OcrqdqbOvbc9D9iat7sQEy7+sa8JsKTwQe3+xKFjt2f/Kx/p2NSOYPABSkWJWE9MXSgw M66JvG1HrOvtDlIm7uS+dvJKTz7uTF1s5t4ww= Original-Received: by 10.114.133.1 with SMTP id g1mr305749wad.149.1222986618432; Thu, 02 Oct 2008 15:30:18 -0700 (PDT) Original-Received: by 10.114.197.8 with HTTP; Thu, 2 Oct 2008 15:30:18 -0700 (PDT) In-Reply-To: <49dd78620809301510q173d1777rd26240ce40f204f0@mail.gmail.com> Content-Disposition: inline X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:7753 Archived-At: 2008/9/30 Neil Jerram : > > Well, ideally we should have a solution that works automatically in > all circumstances... FWIW, I'm actually thinking now that this stack calibration stuff is becoming way too tricky, in at least two ways. 1) The concept of the 'stack debug option being expressed in terms of some other "canonical" combination of OS, compiler and compiler optimization level. (I struggle to describe this clearly, here, and in comments in the code, and I'm sure I would struggle in the manual too - so that's a bad sign!) 2) The complexity that my latest patch adds to the Guile build process. And even with this complexity we still don't cover all the cases (notably cross compiling). Reviewing the history, we find that this work was prompted by people reporting Stack overflow errors when building Guile or when running make check [1]. We also find that such errors were _still_ reported by people who had some version of the calibration patch in place [2]. And there was a case, not yet understood, where the error was apparently caused by configuring without threads [3]. There was also a general discussion of how stack checking is implemented [4], which I think is sufficient to say that we should keep it basically in its current form (rather than implement an eval frame counter, say). [1] http://www.mail-archive.com/bug-guile@gnu.org/msg04401.html [2] http://article.gmane.org/gmane.lisp.guile.bugs/3881 [3] http://thread.gmane.org/gmane.lisp.guile.user/6628/focus=6629 [4] http://www.nabble.com/Re:-stack-overflow-td15467458.html Taking everything together, my thinking now is... - The problem we actually need to solve is getting a stack overflow while running make and/or make check, and there may be other ways of doing that than trying to pick the right number, and to interpret that number such that it has the same effect on all platforms. (For example, I think it would be fine if stack checking was disabled during make and make check, and (post build/install) when loading boot-9.scm. We don't need to guard against C stack overflow when running our own test suite, or when loading boot-9.scm, because overflow in those contexts isn't going to hurt anyone. The point of stack checking is to protect against runaway user/developer code (or Guile code being called from user/developer code).) - Based on [2], it sounds like there is part of this issue that we don't yet understand - i.e. not just the stack growing bigger than the default 20000 words. I plan to try and investigate [2] and [3] more, then hopefully propose something (simpler than my latest patch!). Regards, Neil