From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8826 invoked by alias); 11 Jul 2006 17:59:53 -0000 Received: (qmail 8818 invoked by uid 22791); 11 Jul 2006 17:59:53 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 11 Jul 2006 17:59:51 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6BHxnMc014084; Tue, 11 Jul 2006 13:59:49 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6BHxiwF014321; Tue, 11 Jul 2006 13:59:44 -0400 Received: from [172.16.14.67] (towel.toronto.redhat.com [172.16.14.67]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id k6BHxhve007832; Tue, 11 Jul 2006 13:59:43 -0400 Message-ID: <44B3E70F.4070009@redhat.com> Date: Tue, 11 Jul 2006 17:59:00 -0000 From: Bryce McKinlay User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Ranjit Mathew CC: java-patches@gcc.gnu.org Subject: Re: [MinGW] RFA: Make Stack Traces Work for Interpreted Code on Windows References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org X-SW-Source: 2006-q3/txt/msg00103.txt.bz2 Hi Ranjit, Ranjit Mathew wrote: > When run under the interpreter, an exception-throwing programme > crashes the interpreter on Windows since JvRunMain() does not > occur in the call stack and we once again roam the wilderness of > arbitrary EBP values. > > The fix was to change fallback_backtrace() in > "sysdep/i386/backtrace.h" to stop on _Jv_RunMain() instead since > this does occur in both interpreted and natively-executed call > stacks. (Since this function is overloaded, I needed to use an > interim variable with the appropriate cast to tell the compiler > which of these function variants to pick up.) > Only the main thread will have JvRunMain on the stack - you probably also need to look for the thread-start routine to handle other threads. Note that even then there are some situations (invocation API) where neither _Jv_RunMain or _Jv_ThreadStart will be on the stack. > fallback_backtrace() also does not correctly handle unwinding > through interpreted code. The fix was as simple as copying the > relevant bits of code from _Jv_StackTrace::Unwind_TraceFn() and > adjusting it a little bit. > This part of the patch is a bit awkward - duplicating the interpreter-specific code is fragile and will make maintenance more difficult. Couldn't we instead have fallback_backtrace call the real UnwindTraceFn? I believe _Unwind_context is an opaque type, so it should be possible to have fallback_backtrace pass its own data there. > (I note that under the interpreter we do > not get line numbers for the innermost call frame, even on Linux. > I haven't investigated this issue yet.) > Hmm. There shouldn't be any problems here (on Linux) - do you have a test case? Bryce