[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: trace examples broken in master
From: |
Neil Jerram |
Subject: |
Re: trace examples broken in master |
Date: |
Wed, 16 Sep 2009 01:55:26 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
Neil Jerram <address@hidden> 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