From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Haley <aph@pasanda.cygnus.co.uk>
To: bryce@albatross.co.nz
Cc: rolfwr@ii.uib.no, java-discuss@sourceware.cygnus.com
Subject: Re: Some null pointer method invocations causes segmentation fault
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-ID: <20000328090010.29891.qmail@pasanda.cygnus.co.uk>
References: <38DFFC18.4BE5BF2D@albatross.co.nz>
X-SW-Source: 2000-q1/msg00583.html
Message-ID: <20000401000000.UQdqD3mBQVVz_1UHZvxu72c9l8oqKh4sYEdTXW3jGUs@z>

> Date: Tue, 28 Mar 2000 12:26:00 +1200
> From: Bryce McKinlay <bryce@albatross.co.nz>
> 
> "Rolf W. Rasmussen" wrote:
> 
> > The following program causes a segmentation fault when run, instead of
> > the NullPointerException one would expect.
> >
> > [...]
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x400dfef9 in java.lang.Integer.intValue (this=null)
> >     at ../../../libjava/java/lang/Integer.java:60
> 
> The SIGSEGV you see in the debugger here is normal. The runtime catches
> the segv and maps it into a NullPointerException. Unfortunatly, in these
> cases the __throw() call in libgcc2.so is failing, which appears to be a
> new regression ;-(.

Or, possibly, an incompatibility with this version of Linux.

What's happening here is that the signal handler in libgcj is not
finding the catch region and so calls __terminate().  So what could
cause this to happen?  I've seen it before when the header files
didn't correspond with the kernel; this was just an installation
error.  Another possibility is that the kernel has been changed so
that the process's saved registers are no longer on the stack just
beneath SP when the signal handler is called.  This would be a kernel
bug, as the registers must be saved to match the ABI.  Another
possibility is that libgcj hasn't been compiled with exception ranges
enabled.

The backtrace looks suspicious, as there's a reference to Letext()
just below __throw(), which suggests that the stack is deranged.  Or
maybe not; perhaps just gdb is confused.

Finally, if this problem only occurs when calling functions like
String.length() and booleanValue(), I think I may know what the
problem is.  It's this line in include/i386-signal.h:

  /* Advance the program counter so that it is after the start of the   \
     instruction:  the x86 exception handler expects                    \
     the PC to point to the instruction after a call. */                \
  _eip += 2;                                                            \

which may be causing the return PC to be pointing *after* the end of
an exception region.  

Andrew.