From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: No way out. Date: Mon, 02 Jan 2006 18:54:27 +0000 Message-ID: <877j9i31gc.fsf@ossau.uklinux.net> References: <200511301616.22258.bkorb@gnu.org> <87wthpkyan.fsf@ossau.uklinux.net> <43B69F41.6030509@xs4all.nl> <87hd8pb8o7.fsf@ossau.uklinux.net> <87lkxy3abo.fsf@ossau.uklinux.net> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1136228312 13871 80.91.229.2 (2 Jan 2006 18:58:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 2 Jan 2006 18:58:32 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Jan 02 19:58:27 2006 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EtUsr-0007Rm-NG for guile-devel@m.gmane.org; Mon, 02 Jan 2006 19:58:18 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EtUuQ-000230-1d for guile-devel@m.gmane.org; Mon, 02 Jan 2006 13:59:54 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EtUsi-0000i9-IM for guile-devel@gnu.org; Mon, 02 Jan 2006 13:58:08 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EtUsf-0000e5-SE for guile-devel@gnu.org; Mon, 02 Jan 2006 13:58:07 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EtUsf-0000dN-DO for guile-devel@gnu.org; Mon, 02 Jan 2006 13:58:05 -0500 Original-Received: from [80.84.72.33] (helo=mail3.uklinux.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EtUtk-0005hZ-IW for guile-devel@gnu.org; Mon, 02 Jan 2006 13:59:13 -0500 Original-Received: from laruns (host86-129-132-201.range86-129.btcentralplus.com [86.129.132.201]) by mail3.uklinux.net (Postfix) with ESMTP id 3407A409FBD; Mon, 2 Jan 2006 18:56:24 +0000 (UTC) Original-Received: from laruns (laruns [127.0.0.1]) by laruns (Postfix) with ESMTP id 10D286F714; Mon, 2 Jan 2006 18:54:28 +0000 (GMT) Original-To: hanwen@xs4all.nl In-Reply-To: <87lkxy3abo.fsf@ossau.uklinux.net> (Neil Jerram's message of "Mon, 02 Jan 2006 15:42:51 +0000") User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:5571 Archived-At: Neil Jerram 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 , > body_data=0xbffffbe0, handler=0x40044880 , > 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