From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30884 invoked by alias); 28 Feb 2013 16:30:37 -0000 Received: (qmail 30753 invoked by uid 22791); 28 Feb 2013 16:30:13 -0000 X-Spam-Check-By: sourceware.org Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.83/v0.83-20-g38e4449) with ESMTP; Thu, 28 Feb 2013 16:30:00 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 9AF8F520243; Thu, 28 Feb 2013 17:29:57 +0100 (CET) Date: Thu, 28 Feb 2013 16:48:00 -0000 From: Corinna Vinschen To: gdb-patches@sourceware.org Subject: Re: [patch]: Replace stryoul call to fetch address Message-ID: <20130228162957.GF17724@calimero.vinschen.de> Reply-To: gdb-patches@sourceware.org Mail-Followup-To: gdb-patches@sourceware.org References: <20130227164419.GA16975@calimero.vinschen.de> <512E404E.6070504@redhat.com> <20130227183805.GA30418@calimero.vinschen.de> <512E5B26.7050104@redhat.com> <20130227194235.GB30418@calimero.vinschen.de> <512E7FBB.1080104@redhat.com> <20130228091853.GB30108@calimero.vinschen.de> <20130228162005.GE17724@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20130228162005.GE17724@calimero.vinschen.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2013-02/txt/msg00744.txt.bz2 On Feb 28 17:20, Corinna Vinschen wrote: > On Feb 28 10:18, Corinna Vinschen wrote: > > On Feb 27 21:50, Pedro Alves wrote: > > > On 02/27/2013 07:42 PM, Corinna Vinschen wrote: > > > > > > > The SEGV occurs in exception.c, function throw_exception, though. > > > > The `*current_catcher->exception = exception;' assignment crashes > > > > because current_catcher->exception is NULL. I don't understand yet > > > > why it's NULL, and why the throw_exception function doesn't test > > > > this before trying to write *current_catcher->exception. > > > > > > What's the backtrace like? > > > > > > There's always a top level catcher installed (gdb_main -> catch_errors) > > > Unless, hmm, waitaminut. What's the backtrace like? I just realized > > > a very early exception in captured_main can result in bad > > > things like that. > > > > I didn't really debug this in depth yet. Keep in mind that 64 bit > > Cygwin is still in development so there are heinous bugs to be expected. > > This crash is probably a result of an underlying Cygwin bug. > > I debugged this further and it seems this is a bug in newlib's > definition of setjmp_buf: > > typedef _JBTYPE sigjmp_buf[_JBLEN+1+(sizeof (sigset_t)/sizeof (_JBTYPE))]; > > If sizeof(sigset_t) is less than sizeof(_JBTYPE), then the result of the > division is zero, and the buffer is too short by sizeof(sigset_t). > The element preceeding the exception pointer in `struct catcher' is a > sigjmp_buf. So exception is NULL, because the sigsetjmp call overwrites > exeception with a signal mask. > > I'm going to replace the expression in newlib's setjmp.h with > > typedef _JBTYPE sigjmp_buf[_JBLEN+1+((sizeof (_JBTYPE) + sizeof (sigset_t) - 1) > /sizeof (_JBTYPE))]; > > which makes sure that the result of the division is at least 1. This > change requires to rebuild the toolchain from scratch so it will take > some time to see the result of the change. Well, not *that* long, actually. This patch did it. x86_64 GDB is up and running :) Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat