From mboxrd@z Thu Jan  1 00:00:00 1970
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
Message-ID: <38E17616.538EA0C0@albatross.co.nz>
References: <20000328090010.29891.qmail@pasanda.cygnus.co.uk>
X-SW-Source: 2000-q1/msg00586.html
Message-ID: <20000401000000.RmAsUXUvTMwDOzesYpvOMWiSYKCQTPXO0535EEi8g84@z>

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 ]