/[guile]/guile/guile-core/BUGS
ViewVC logotype

Diff of /guile/guile-core/BUGS

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.13 by ttn, Wed Feb 6 23:00:37 2002 UTC revision 1.14 by ossau, Wed Feb 20 21:27:57 2002 UTC
# Line 343  Thomas Wawrzinek sez: Line 343  Thomas Wawrzinek sez:
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]

Legend:
Removed from v.1.13  
changed lines
  Added in v.1.14

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26