From b30366b6b99b89e0aeeb23a9ed6b5f076ece48eb Mon Sep 17 00:00:00 2001 From: Neil Jerram Date: Wed, 20 Feb 2002 21:27:57 +0000 Subject: [PATCH] * Add two new bugs to BUGS file. --- BUGS | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) diff --git a/BUGS b/BUGS index d3a2ecb32..37016476c 100644 --- a/BUGS +++ b/BUGS @@ -342,5 +342,73 @@ Thomas Wawrzinek sez: > To avoid such behavior, would it be sensible to have guile indicate > a wrong usage error or something? + +bug 13 -- incorrect error reporting after stack overflow +reported-by: Panagiotis Vossos / 2002-02-19 +fixed: not-yet + +Panagiotis Vossos sez: + +I have guile 1.5.4 installed and I discovered something strange. + +guile> (define (foo n) (+ n (foo n))) +guile> (foo 10) +ERROR: Stack overflow +ABORT: (stack-overflow) +guile> thisisabug +: In expression thisisabug: +: Unbound variable: thisisabug +ABORT: (unbound-variable) +guile> (foo 10) +: In expression thisisabug: +: Stack overflow +ABORT: (stack-overflow) + +The last message shows the previous unbound variable 'thisisabug'. +'foo' is just an example, this seems to happen for every function that +causes overflow. It's not serious, but it sure looks misleading.. + +Neil Jerram sez: + +It's something to do with the way that debug info frames cope with +stack overflow. + + +bug 14 -- strange gc loop caused by trap misuse +reported-by: Neil Jerram / 2002-02-03 +fixed: not-yet + +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. + [BUGS ends here]