public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
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: Tue, 28 Mar 2000 01:00:00 -0000	[thread overview]
Message-ID: <20000328090010.29891.qmail@pasanda.cygnus.co.uk> (raw)
In-Reply-To: <38DFFC18.4BE5BF2D@albatross.co.nz>

> 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.

WARNING: multiple messages have this Message-ID
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	[thread overview]
Message-ID: <20000328090010.29891.qmail@pasanda.cygnus.co.uk> (raw)
Message-ID: <20000401000000.UQdqD3mBQVVz_1UHZvxu72c9l8oqKh4sYEdTXW3jGUs@z> (raw)
In-Reply-To: <38DFFC18.4BE5BF2D@albatross.co.nz>

> 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.

  reply	other threads:[~2000-03-28  1:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-27 14:52 Rolf W. Rasmussen
2000-03-27 16:21 ` Bryce McKinlay
2000-03-28  1:00   ` Andrew Haley [this message]
2000-03-28 19:14     ` PR libgcj/184 [was Re: Re: Some null pointer method invocations causes segmentation fault] Bryce McKinlay
2000-03-30  3:06       ` Bryce McKinlay
2000-04-01  0:00         ` Bryce McKinlay
2000-04-01  0:00       ` Bryce McKinlay
2000-04-01  0:00     ` Some null pointer method invocations causes segmentation fault Andrew Haley
2000-04-01  0:00   ` Bryce McKinlay
2000-04-01  0:00 ` Rolf W. Rasmussen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20000328090010.29891.qmail@pasanda.cygnus.co.uk \
    --to=aph@pasanda.cygnus.co.uk \
    --cc=bryce@albatross.co.nz \
    --cc=java-discuss@sourceware.cygnus.com \
    --cc=rolfwr@ii.uib.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).