libgcj/1225: PR libgcj/184 [was Re: Re: Some null pointer method invocations causes segmentation fault]

[Bryce McKinlay]

>Number:         1225
>Category:       libgcj
>Synopsis:       PR libgcj/184 [was Re: Re: Some null pointer method invocations causes
>Confidential:   yes
>Severity:       serious
>Priority:       medium
>Responsible:    green
>State:          closed
>Class:          sw-bug
>Submitter-Id:   unknown
>Arrival-Date:   Wed Dec 20 12:17:58 PST 2000
>Closed-Date:    Thu Mar 30 11:15:17 PST 2000
>Last-Modified:  Thu Mar 30 11:16:02 PST 2000
>Originator:     
>Release:        
>Organization:
>Environment:

>Description:
 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 ]
 
 
>How-To-Repeat:

>Fix:

>Release-Note:

>Audit-Trail:

Formerly PR libgcj/185

State-Changed-From-To: open->closed
State-Changed-By: tromey
State-Changed-When: Thu Mar 30 11:15:17 2000
State-Changed-Why:
    This PR was created by mistake

From: tromey@cygnus.com
To: bryce@albatross.co.nz, green@cygnus.com, java-gnats@sourceware.cygnus.com
Cc:  
Subject: Re: libgcj/185
Date: 30 Mar 2000 19:15:17 -0000

 Synopsis: PR libgcj/184 [was Re: Re: Some null pointer method invocations causes
 
 State-Changed-From-To: open->closed
 State-Changed-By: tromey
 State-Changed-When: Thu Mar 30 11:15:17 2000
 State-Changed-Why:
     This PR was created by mistake
 
 http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=185&database=java
>Unformatted:
  segmentation fault]