[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: No way out.
From: |
Neil Jerram |
Subject: |
Re: No way out. |
Date: |
Mon, 02 Jan 2006 18:54:27 +0000 |
User-agent: |
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) |
Neil Jerram <address@hidden> 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
- Re: No way out., Han-Wen Nienhuys, 2006/01/01
- Message not available
- Re: No way out., Han-Wen Nienhuys, 2006/01/01
- Re: No way out., Neil Jerram, 2006/01/02
- Re: No way out.,
Neil Jerram <=
- Backtrace and enhanced catch, Neil Jerram, 2006/01/04
- Re: Backtrace and enhanced catch, Neil Jerram, 2006/01/14
- Re: Backtrace and enhanced catch, Marius Vollmer, 2006/01/22
- Re: Backtrace and enhanced catch, Neil Jerram, 2006/01/23
- Re: Backtrace and enhanced catch, Marius Vollmer, 2006/01/24
- Re: Backtrace and enhanced catch, Ludovic Courtès, 2006/01/16
- Re: Backtrace and enhanced catch, Neil Jerram, 2006/01/18
- Re: Backtrace and enhanced catch, Ludovic Courtès, 2006/01/19
- Re: Backtrace and enhanced catch, Neil Jerram, 2006/01/21
- Re: Backtrace and enhanced catch, Kevin Ryde, 2006/01/26