Re: SIGFPE -> ArithmeticException ?

[Andrew Haley <aph@pasanda.cygnus.co.uk>]

> Date: Thu, 01 Jul 1999 18:46:03 +1200
> From: Bryce McKinlay <bryce@albatross.co.nz>
> 
> Andrew Haley wrote:
> 
> > I know that this is going to sound pathetic, but after tracing through
> > this for a while I think you have a broken pthreads library.
> 
> Admittedly, some things on reason have been hacked around with a bit,
> but nothing has touched pthreads, AFAIK. Just to be sure, I have just
> done a complete rebuild of gcc (current 2.96 snapshot) and libgcj on
> another machine that is a *completely* standard Redhat 6.0
> installation (default kernel and all) - same problem.
> 
> > Here's pathia, a machine here.  Note that it has _almost_ the same
> > kernel as yours:
> 
> What libc version are your test machines running? Everything here is
> running Redhat's glibc 2.1.1-6, and I suspect that this problem
> actually has more to do with glibc than the kernel itself.

Yes, that's right.  What happens is that the kernel correctly delivers
the signal with the correct register context, is trapped by the
pthread library, and then the pthread library calls the user's handler
without bothering to pass along the context.  The thing that I don't
understand is why the machines that I've tried _don't_ exhibit the
problem.

> > See what I mean?  On pathia, the value in register gregs[EIP] is the
> > value in the program counter at the time the signal happened.  On
> > reason it's a null pointer, and we're doomed.
> >
> > It looks to me like your pthreads library traps the signal but doesn't
> > pass along the context.  Could it be that your pthreads library is
> > older than the kernel?
> 
> OK, so using the "new" signal interface, gregs comes out as a null
> pointer. Under the old interface, the register values come out looking
> fine (at least to my untrained eye)

They weren't fine when I looked: the registers were not correct.

> , but we still get _Jv_Throw()
> aborting. Any idea why the old interface isn't working then? (using
> either the original code and using a casted "static void my_handler
> (int sig, struct sigcontext_struct ctx);" signal handler, as suggested
> by Anthony, gives the same results)

I'd expect it to: they do the same thing, it's just that Anthony's
suggestion is cleaner.  If the register values had been correct, I'm
pretty sure that the code would have worked.

I just wish that I could duplicate the fault on a machine that I have
easier access to.
  
Andrew.