public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
From: Bryce McKinlay <bryce@albatross.co.nz>
To: Andrew Haley <aph@pasanda.cygnus.co.uk>
Cc: rolfwr@ii.uib.no, java-discuss@sourceware.cygnus.com,
	java-gnats@sourceware.cygnus.com
Subject: PR libgcj/184 [was Re: Re: Some null pointer method invocations causes segmentation fault]
Date: Sat, 01 Apr 2000 00:00:00 -0000	[thread overview]
Message-ID: <38E17616.538EA0C0@albatross.co.nz> (raw)
Message-ID: <20000401000000.RmAsUXUvTMwDOzesYpvOMWiSYKCQTPXO0535EEi8g84@z> (raw)
In-Reply-To: <20000328090010.29891.qmail@pasanda.cygnus.co.uk>

I think there are two parts to the problem. The first is our old friend PR
#2, ie a NullPointerException doesn't get generated automatically when
calling a final method on a null reference. This means that we are relying on
the exception being thrown from inside the call itself, rather than when the
call is attempted, as it should be.

Andrew Haley wrote:

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

That would sort-of seem consistent with what I am observing. ie - this code
crashes:

public class NPE1
{
  public static void main(String[] args)
  {
    NPE1 n = null;
    System.out.println (n.foo());
  }

  int x = 2;

  final int foo()
  {
    return x;
  }
}

while this code works:

public class NPE2
{
  public static void main(String[] args)
  {
    NPE2 n = null;
    n.foo();
  }

  int x = 2;

  final int foo()
  {
    System.out.println ("foo");
    return x;
  };
}

The only difference between these examples is the extra padding statement
above the attempted access of "x" in the second case.

However, I commented out the "_eip += 2;" code in i386-signal.h (and did a
full libgcj rebuild), and it apparantly made no difference - the working case
still works and the failing case still fails.

I'm pretty sure this used to work (at least, I'm pretty sure I would have
noticed it before if it didn't). The only thing I've updated recently is libc
(to 2.1.3) and, of course, gcc. If you think it might be worth going back to
an older gcc/libgcj and checking those, I can do that.

regards

  [ bryce ]


  reply	other threads:[~2000-04-01  0:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-27 14:52 Some null pointer method invocations causes segmentation fault Rolf W. Rasmussen
2000-03-27 16:21 ` Bryce McKinlay
2000-03-28  1:00   ` Andrew Haley
2000-03-28 19:14     ` Bryce McKinlay [this message]
2000-03-30  3:06       ` PR libgcj/184 [was Re: Re: Some null pointer method invocations causes segmentation fault] 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=38E17616.538EA0C0@albatross.co.nz \
    --to=bryce@albatross.co.nz \
    --cc=aph@pasanda.cygnus.co.uk \
    --cc=java-discuss@sourceware.cygnus.com \
    --cc=java-gnats@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).