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: trace examples broken in master Date: Wed, 16 Sep 2009 01:55:26 +0100 Message-ID: <87k4zzr9mp.fsf@ossau.uklinux.net> References: <2bc5f8210907091222v6d3a3b8cqd91050a02b9d4f9c@mail.gmail.com> <87r5wj6626.fsf@arudy.ossau.uklinux.net> <87r5uty5qh.fsf@arudy.ossau.uklinux.net> <2bc5f8210908300810v7afae448x13b1acb88ce113b6@mail.gmail.com> <87ab1enwe4.fsf@arudy.ossau.uklinux.net> <87ocpbrhzo.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 1253062572 4653 80.91.229.12 (16 Sep 2009 00:56:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Sep 2009 00:56:12 +0000 (UTC) Cc: guile-devel To: Julian Graham Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Sep 16 02:56:05 2009 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 1MnioW-00028J-Vw for guile-devel@m.gmane.org; Wed, 16 Sep 2009 02:56:05 +0200 Original-Received: from localhost ([127.0.0.1]:59850 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MnioW-000253-44 for guile-devel@m.gmane.org; Tue, 15 Sep 2009 20:56:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mnio4-00020v-85 for guile-devel@gnu.org; Tue, 15 Sep 2009 20:55:36 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mninz-0001zn-EO for guile-devel@gnu.org; Tue, 15 Sep 2009 20:55:35 -0400 Original-Received: from [199.232.76.173] (port=60665 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mninz-0001zk-9e for guile-devel@gnu.org; Tue, 15 Sep 2009 20:55:31 -0400 Original-Received: from mail3.uklinux.net ([80.84.72.33]:34406) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mniny-0003Hs-ON for guile-devel@gnu.org; Tue, 15 Sep 2009 20:55:31 -0400 Original-Received: from arudy (host86-147-112-99.range86-147.btcentralplus.com [86.147.112.99]) by mail3.uklinux.net (Postfix) with ESMTP id D1B7B1F6C9C; Wed, 16 Sep 2009 01:55:27 +0100 (BST) Original-Received: from arudy (arudy [127.0.0.1]) by arudy (Postfix) with ESMTP id 0EB3938021; Wed, 16 Sep 2009 01:55:27 +0100 (BST) In-Reply-To: <87ocpbrhzo.fsf@ossau.uklinux.net> (Neil Jerram's message of "Tue, 15 Sep 2009 22:54:51 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 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:9321 Archived-At: Neil Jerram writes: > There is an unexpected "warning: stack count incorrect!", though. I'll > look into that. It is fixed (i.e. doesn't occur) with the following changes. diff --git a/libguile/stacks.c b/libguile/stacks.c index 45566ca..849a9c7 100644 --- a/libguile/stacks.c +++ b/libguile/stacks.c @@ -143,6 +143,11 @@ stack_depth (scm_t_debug_frame *dframe, scm_t_ptrdiff offset, SCM vmframe, { scm_t_debug_info *info = RELOC_INFO (dframe->info, offset); scm_t_debug_info *vect = RELOC_INFO (dframe->vect, offset); + /* If current frame is a macro during expansion, we should + skip the previously recorded macro transformer + application frame. */ + if (SCM_MACROEXPP (*dframe) && n > 0) + --n; n += (info - vect) / 2 + 1; /* Data in the apply part of an eval info frame comes from previous stack frame if the scm_t_debug_info vector is overflowed. */ Here n is the running stack depth. Missing this decrement will cause the "stack count incorrect" warning but is actually benign, as it only means that scm_make_stack allocates a bit more space for the stack than it really needs. @@ -178,7 +183,10 @@ stack_depth (scm_t_debug_frame *dframe, scm_t_ptrdiff offset, SCM vmframe, ++n; /* increment for non-program apply frame */ } else - ++n; + { + abort (); + ++n; + } } if (dframe && SCM_VOIDFRAMEP (*dframe)) *id = RELOC_INFO(dframe->vect, offset)[0].id; I'm pretty sure this last else branch is unhittable, hence the added abort (). @@ -282,6 +290,7 @@ read_frames (scm_t_debug_frame *dframe, scm_t_ptrdiff offset, { *(iframe - 1) = *iframe; --iframe; + ++n; } info = RELOC_INFO (dframe->info, offset); vect = RELOC_INFO (dframe->vect, offset); Here n is the number of frames still unused in the allocated stack object. Missing this increment will cause the "stack count incorrect" warning, and will make read_frames think it's filled up all the available stack frames when there's actually still one frame unused; it's not benign, because it can cause information to be missing from a stack trace. (But unfortunately it doesn't appear to be the fix for the missing VM frames problem.) Neil