Re: [patch]: Replace stryoul call to fetch address

[Corinna Vinschen <vinschen at redhat dot com>]

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