GC loop

[Neil Jerram]

Using the current unstable CVS Guile...

Running under gdb, type in the following:

(gdb) run -q
Starting program: /usr/local/bin/guile -q
guile> (trap-set! enter-frame-handler (lambda () 1))
(exit-frame-handler #f apply-frame-handler #f enter-frame-handler #<procedure 
#f ()> traps)
guile> (trap-enable 'enter-frame)

There is no response.  Wait a few seconds, and then C-c to send an
interrupt.  You'll find that the call stack shows a huge number of
recursive calls to scm_gc_mark (about 4000 per second waited on my
box).  (If you don't see scm_gc_mark immediately, you may have
interrupted too quickly: let it run for another second and then C-c
again.)

Here's as much of an explanation as I can offer...  The intended
effect of the two `trap' lines above is that the evaluator calls the
specified procedure every time it enters a new evaluation frame or is
about to perform an application.  However, the procedure above doesn't
accept the right number of arguments, so the attempt to call it gives
rise to a wrong-num-args error, which (I presume) jumps us out of that
level of the evaluator and is caught by the usual REPL machinery in
boot-9.scm.

Then, the next time that we need to GC, we hit this scm_gc_mark loop.
My guess is that something about the trap+error scenario has left data
or the stack in a state which exposes a bug in the GC.

        Neil