Re: SIGFPE -> ArithmeticException ?

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

> Date: Fri, 25 Jun 1999 15:54:11 +1200
> From: Bryce McKinlay <bryce@albatross.co.nz>
> 
> Andrew Haley wrote:
> 
> > Unfortunately, I can't duplicate your problem.  This *is* something we
> > regularly test.
> >
> > Please run the program under gdb.  When the SIGFPE occurs, put a
> > breakpoint on 'catch-fpe'.  When you get to 'catch-fpe', print a
> > backtrace and mail it to me.
> 
> Hi Andrew,
> 
> Here's a log of my gdb session. It doesnt seem particularly interesting:
> 
> [bryce@reason tests]$ gdb ./divbyzero
> GNU gdb 4.17.0.11 with Linux support
> Continuing.
> 
> Breakpoint 1, catch_fpe (_dummy=8) at ../../../libjava/prims.cc:76
> 76        _Jv_Throw (arithexception);
> Current language:  auto; currently c++
> (gdb) bt
> #0  catch_fpe (_dummy=8) at ../../../libjava/prims.cc:76

Actually, it is very interesting, because it proves that the FPE is
being caught and that catch_fpe is being called.  Now step over the
HANDLE_DIVIDE_OVERFLOW to the point just before _Jv_Throw is called
and do a backtrace again.  The stack chain should be complete, with
the return pointing to the point where the division by zero occurred.

In your build directory, include/java-signal.h should be a symbolic
link to include/i386-signal.h.  Check that.

The problem might be because the register frame on the stack at the
point when catch_fpe is called is not in the form expected by the
exception handler.  This is how we find out.

If that's so, I need to know exactly what version of the Linux kernel
you're running.  It might be best if I could run your kernel or even
if I could rlogin to your machine to see what is happening.

If the HANDLE_DIVIDE_OVERFLOW macro from include/i386-signal hasn't
been exapanded in catch_fpe, your libgcj hasn't been built correctly.

If in doubt, please send me a gdb diassembly of catch_fpe.

Thanks,
Andrew.