343 |
> a wrong usage error or something? |
> a wrong usage error or something? |
344 |
|
|
345 |
|
|
346 |
|
bug 13 -- incorrect error reporting after stack overflow |
347 |
|
reported-by: Panagiotis Vossos <jacbre@internet.gr> / 2002-02-19 |
348 |
|
fixed: not-yet |
349 |
|
|
350 |
|
Panagiotis Vossos sez: |
351 |
|
|
352 |
|
I have guile 1.5.4 installed and I discovered something strange. |
353 |
|
|
354 |
|
guile> (define (foo n) (+ n (foo n))) |
355 |
|
guile> (foo 10) |
356 |
|
ERROR: Stack overflow |
357 |
|
ABORT: (stack-overflow) |
358 |
|
guile> thisisabug |
359 |
|
<unnamed port>: In expression thisisabug: |
360 |
|
<unnamed port>: Unbound variable: thisisabug |
361 |
|
ABORT: (unbound-variable) |
362 |
|
guile> (foo 10) |
363 |
|
<unnamed port>: In expression thisisabug: |
364 |
|
<unnamed port>: Stack overflow |
365 |
|
ABORT: (stack-overflow) |
366 |
|
|
367 |
|
The last message shows the previous unbound variable 'thisisabug'. |
368 |
|
'foo' is just an example, this seems to happen for every function that |
369 |
|
causes overflow. It's not serious, but it sure looks misleading.. |
370 |
|
|
371 |
|
Neil Jerram sez: |
372 |
|
|
373 |
|
It's something to do with the way that debug info frames cope with |
374 |
|
stack overflow. |
375 |
|
|
376 |
|
|
377 |
|
bug 14 -- strange gc loop caused by trap misuse |
378 |
|
reported-by: Neil Jerram <neil@ossau.uklinux.net> / 2002-02-03 |
379 |
|
fixed: not-yet |
380 |
|
|
381 |
|
Neil Jerram sez: |
382 |
|
|
383 |
|
Using the current unstable CVS Guile... |
384 |
|
|
385 |
|
Running under gdb, type in the following: |
386 |
|
|
387 |
|
(gdb) run -q |
388 |
|
Starting program: /usr/local/bin/guile -q |
389 |
|
guile> (trap-set! enter-frame-handler (lambda () 1)) |
390 |
|
(exit-frame-handler #f apply-frame-handler #f enter-frame-handler #<procedure #f ()> traps) |
391 |
|
guile> (trap-enable 'enter-frame) |
392 |
|
|
393 |
|
There is no response. Wait a few seconds, and then C-c to send an |
394 |
|
interrupt. You'll find that the call stack shows a huge number of |
395 |
|
recursive calls to scm_gc_mark (about 4000 per second waited on my |
396 |
|
box). (If you don't see scm_gc_mark immediately, you may have |
397 |
|
interrupted too quickly: let it run for another second and then C-c |
398 |
|
again.) |
399 |
|
|
400 |
|
Here's as much of an explanation as I can offer... The intended |
401 |
|
effect of the two `trap' lines above is that the evaluator calls the |
402 |
|
specified procedure every time it enters a new evaluation frame or is |
403 |
|
about to perform an application. However, the procedure above doesn't |
404 |
|
accept the right number of arguments, so the attempt to call it gives |
405 |
|
rise to a wrong-num-args error, which (I presume) jumps us out of that |
406 |
|
level of the evaluator and is caught by the usual REPL machinery in |
407 |
|
boot-9.scm. |
408 |
|
|
409 |
|
Then, the next time that we need to GC, we hit this scm_gc_mark loop. |
410 |
|
My guess is that something about the trap+error scenario has left data |
411 |
|
or the stack in a state which exposes a bug in the GC. |
412 |
|
|
413 |
|
|
414 |
[BUGS ends here] |
[BUGS ends here] |