Re: No way out.

[Neil Jerram <neil@ossau.uklinux.net>]

Neil Jerram <neil@ossau.uklinux.net> writes:

> In 1.7.x, we don't call scm_handle_by_message, because there is a
> matching catch which was set up as part of scm_with_guile.  The C
> backtrace after jumping back out to this catch is:
>
> #0  scm_internal_catch (tag=0x1, body=0x40044850 <c_body>, 
>     body_data=0xbffffbe0, handler=0x40044880 <c_handler>, 
>     handler_data=0xbffffbe0) at throw.c:158
> #1  0x4004482c in scm_i_with_continuation_barrier (body=0x1, body_data=0x1, 
>     handler=0x1, handler_data=0x1) at continuations.c:336
> #2  0x40044913 in scm_c_with_continuation_barrier (func=0x1, data=0x1)
>     at continuations.c:378
> #3  0x400b53a0 in scm_i_with_guile_and_parent (func=0x1, data=0x1, parent=0x1)
>     at threads.c:645
> #4  0x400b5350 in scm_with_guile (func=0x1, data=0x1) at threads.c:633
> #5  0x400732a1 in scm_boot_guile (argc=1, argv=0x1, main_func=0x1, closure=0x1)
>     at init.c:350
> #6  0x080489c6 in main (argc=1, argv=0x1) at guile.c:74

The problem is that the use of scm_internal_catch here means that the
stack is unwound before the code in c_handler can get at it.
c_handler has code in it that would print a backtrace if the stack was
still available, but it isn't; to be precise, the "else if
(SCM_JMPBUFP (jmpbuf))" code in scm_ithrow sets
scm_i_last_debug_frame() back to NULL before the catch handler is called.

I think the only really good fix for this would be to implement an
exception handling mechanism that doesn't rely on lazy catch, along
the lines of SRFI-34.  Then the exception handler could display the
backtrace.

Alternatively we could make a shorter term fix by adding a lazy catch
inside the scm_internal_catch, and using the lazy catch handler either
to display the backtrace directly, or to save off the stack so it can
be displayed later.  scm_internal_stack_catch does the latter, by
setting the value of the-last-stack, so we could use that, but would
it be correct for uses of with-continuation-barrier to overwrite
the-last-stack?  I'm not sure.

One other query/possibility...  Does with-continuation-barrier _have_
to include a (catch #t ...)?  If it didn't, there wouldn't be a catch
on the wind list, and so the exception would be caught and handled by
the fallback code in scm_ithrow(), as is the case for 1.6.

Thoughts?
        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel