Re: trace examples broken in master

[Neil Jerram]

Neil Jerram <n...@ossau.uklinux.net> 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