summary: strange gc loop caused by trap misuse reported: Neil Jerram , 2002-02-03 Neil Jerram sez: 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 # 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.