* libgcj/1225: PR libgcj/184 [was Re: Re: Some null pointer method invocations causes segmentation fault]
[not found] <20000328090010.29891.qmail@pasanda.cygnus.co.uk>
@ 2000-12-20 12:23 ` Bryce McKinlay
2000-12-20 12:22 ` libgcj/1226: " Bryce McKinlay
0 siblings, 1 reply; 2+ messages in thread
From: Bryce McKinlay @ 2000-12-20 12:23 UTC (permalink / raw)
To: Andrew Haley; +Cc: rolfwr, java-discuss, java-gnats
>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]
^ permalink raw reply [flat|nested] 2+ messages in thread