From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23072 invoked by alias); 28 Feb 2013 16:20:45 -0000 Received: (qmail 23017 invoked by uid 22791); 28 Feb 2013 16:20:15 -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:20:08 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id B9D5A520243; Thu, 28 Feb 2013 17:20:05 +0100 (CET) Date: Thu, 28 Feb 2013 16:33:00 -0000 From: Corinna Vinschen To: gdb-patches@sourceware.org Subject: Re: [patch]: Replace stryoul call to fetch address Message-ID: <20130228162005.GE17724@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20130228091853.GB30108@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/msg00743.txt.bz2 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. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat