Neil Jerram <[EMAIL PROTECTED]> 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
[email protected]
http://lists.gnu.org/mailman/listinfo/guile-devel
