public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* Some null pointer method invocations causes segmentation fault
@ 2000-03-27 14:52 Rolf W. Rasmussen
  2000-03-27 16:21 ` Bryce McKinlay
  2000-04-01  0:00 ` Rolf W. Rasmussen
  0 siblings, 2 replies; 10+ messages in thread
From: Rolf W. Rasmussen @ 2000-03-27 14:52 UTC (permalink / raw)
  To: java-discuss

The following program causes a segmentation fault when run, instead of
the NullPointerException one would expect.

--------
public class NullPointerExceptionTest {
    public static void main(String[] args) {
        ((Integer) null).intValue();
    }
}
--------

Starting
program: /home/debian/rolfwr/prg/testgcj/./NullPointerExceptionTest

[...]
Program received signal SIGSEGV, Segmentation fault.
0x400dfef9 in java.lang.Integer.intValue (this=null)
    at ../../../libjava/java/lang/Integer.java:60
60          return value;
Current language:  auto; currently java
(gdb) bt
#0  0x400dfef9 in java.lang.Integer.intValue (this=null)
    at ../../../libjava/java/lang/Integer.java:60
#1  0x804af63 in NullPointerExceptionTest.main (args=@8081ff0)
    at NullPointerExceptionTest.java:3
#2  0x4013160a in gnu::gcj::runtime::FirstThread::run (this=@8064ea0)
[...]

Other one-liners that trigger the same problem:

    ((String) null).length();
    ((java.util.Vector) null).size();
    Boolean ref = null; ref.booleanValue();

I've compiled/run with gcj/libgcj pulled from CVS on 27. March.
gcc version 2.96 20000327 (experimental) on i586-pc-linux-gnu

--
Rolf W. Rasmussen

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Some null pointer method invocations causes segmentation fault
  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-04-01  0:00   ` Bryce McKinlay
  2000-04-01  0:00 ` Rolf W. Rasmussen
  1 sibling, 2 replies; 10+ messages in thread
From: Bryce McKinlay @ 2000-03-27 16:21 UTC (permalink / raw)
  To: Rolf W. Rasmussen; +Cc: java-discuss

"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 ;-(.

Program received signal SIGABRT, Aborted.
0x40257d41 in __kill () from /lib/libc.so.6
(gdb) bt
#0  0x40257d41 in __kill () from /lib/libc.so.6
#1  0x4021b217 in raise (sig=6) at signals.c:65
#2  0x402590d8 in abort () at ../sysdeps/generic/abort.c:88
#3  0x804b59e in __default_terminate () at ../../gcc/libgcc2.c:3036
#4  0x804b5bc in __terminate () at ../../gcc/libgcc2.c:3036
#5  0x804c1fc in throw_helper (eh=@8083618, pc=@400e75ba,
my_udata=@bf7ffb0c,
    offset_p=@bf7ffb08) at ../../gcc/libgcc2.c:3170
#6  0x804c3f1 in __throw () at ../../gcc/libgcc2.c:3170
#7  0x400a98ba in Letext () at ../../../libjava/exception.cc:161
#8  0x4009f238 in catch_segv () at ../../../libjava/prims.cc:94
#9  0x400e75bb in java.lang.String.length (this=null)
    at ../../../libjava/java/lang/String.java:130
#10 0x804d97a in test.main (args=@8086ff0) at test.java:6
#11 0x40133420 in gnu::gcj::runtime::FirstThread::run (this=@8069ea0)
    at ../../../libjava/gnu/gcj/runtime/natFirstThread.cc:52
#12 0x4013e9ee in java::lang::Thread::run_ (obj=@8069ea0)
    at ../../../libjava/java/lang/natThread.cc:191
#13 0x40150821 in really_start (x=@808aff8)
    at ../../../libjava/posix-threads.cc:344
#14 0x402007aa in GC_start_routine (arg=@808bfe0)
    at ../../../boehm-gc/linux_threads.c:553
#15 0x40218b85 in pthread_start_thread (arg=@bf7ffe40) at manager.c:241


Could you enter a PR?
 http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?user=guest&password=guest&database=java&cmd=login

thanks

  [ bryce ]


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Some null pointer method invocations causes segmentation fault
  2000-03-27 16:21 ` Bryce McKinlay
@ 2000-03-28  1:00   ` Andrew Haley
  2000-03-28 19:14     ` PR libgcj/184 [was Re: Re: Some null pointer method invocations causes segmentation fault] Bryce McKinlay
  2000-04-01  0:00     ` Some null pointer method invocations causes segmentation fault Andrew Haley
  2000-04-01  0:00   ` Bryce McKinlay
  1 sibling, 2 replies; 10+ messages in thread
From: Andrew Haley @ 2000-03-28  1:00 UTC (permalink / raw)
  To: bryce; +Cc: rolfwr, java-discuss

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* PR libgcj/184 [was Re: Re: Some null pointer method invocations causes segmentation fault]
  2000-03-28  1:00   ` Andrew Haley
@ 2000-03-28 19:14     ` Bryce McKinlay
  2000-03-30  3:06       ` Bryce McKinlay
  2000-04-01  0:00       ` Bryce McKinlay
  2000-04-01  0:00     ` Some null pointer method invocations causes segmentation fault Andrew Haley
  1 sibling, 2 replies; 10+ messages in thread
From: Bryce McKinlay @ 2000-03-28 19:14 UTC (permalink / raw)
  To: Andrew Haley; +Cc: rolfwr, java-discuss, java-gnats

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 ]


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: PR libgcj/184 [was Re: Re: Some null pointer method invocations causes segmentation fault]
  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
  1 sibling, 1 reply; 10+ messages in thread
From: Bryce McKinlay @ 2000-03-30  3:06 UTC (permalink / raw)
  To: Andrew Haley, rolfwr, java-discuss, java-gnats

Bryce McKinlay wrote:

> 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;
>   }
> }

Update:  I tried this on gcc-2.95.2 + java patches, and it worked fine using the
same libgcj. I think it is a compiler or libgcc bug.

regards

  [ bryce ]


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: PR libgcj/184 [was Re: Re: Some null pointer method invocations causes segmentation fault]
  2000-03-30  3:06       ` Bryce McKinlay
@ 2000-04-01  0:00         ` Bryce McKinlay
  0 siblings, 0 replies; 10+ messages in thread
From: Bryce McKinlay @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Andrew Haley, rolfwr, java-discuss, java-gnats

Bryce McKinlay wrote:

> 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;
>   }
> }

Update:  I tried this on gcc-2.95.2 + java patches, and it worked fine using the
same libgcj. I think it is a compiler or libgcc bug.

regards

  [ bryce ]


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Some null pointer method invocations causes segmentation fault
  2000-03-27 16:21 ` Bryce McKinlay
  2000-03-28  1:00   ` Andrew Haley
@ 2000-04-01  0:00   ` Bryce McKinlay
  1 sibling, 0 replies; 10+ messages in thread
From: Bryce McKinlay @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Rolf W. Rasmussen; +Cc: java-discuss

"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 ;-(.

Program received signal SIGABRT, Aborted.
0x40257d41 in __kill () from /lib/libc.so.6
(gdb) bt
#0  0x40257d41 in __kill () from /lib/libc.so.6
#1  0x4021b217 in raise (sig=6) at signals.c:65
#2  0x402590d8 in abort () at ../sysdeps/generic/abort.c:88
#3  0x804b59e in __default_terminate () at ../../gcc/libgcc2.c:3036
#4  0x804b5bc in __terminate () at ../../gcc/libgcc2.c:3036
#5  0x804c1fc in throw_helper (eh=@8083618, pc=@400e75ba,
my_udata=@bf7ffb0c,
    offset_p=@bf7ffb08) at ../../gcc/libgcc2.c:3170
#6  0x804c3f1 in __throw () at ../../gcc/libgcc2.c:3170
#7  0x400a98ba in Letext () at ../../../libjava/exception.cc:161
#8  0x4009f238 in catch_segv () at ../../../libjava/prims.cc:94
#9  0x400e75bb in java.lang.String.length (this=null)
    at ../../../libjava/java/lang/String.java:130
#10 0x804d97a in test.main (args=@8086ff0) at test.java:6
#11 0x40133420 in gnu::gcj::runtime::FirstThread::run (this=@8069ea0)
    at ../../../libjava/gnu/gcj/runtime/natFirstThread.cc:52
#12 0x4013e9ee in java::lang::Thread::run_ (obj=@8069ea0)
    at ../../../libjava/java/lang/natThread.cc:191
#13 0x40150821 in really_start (x=@808aff8)
    at ../../../libjava/posix-threads.cc:344
#14 0x402007aa in GC_start_routine (arg=@808bfe0)
    at ../../../boehm-gc/linux_threads.c:553
#15 0x40218b85 in pthread_start_thread (arg=@bf7ffe40) at manager.c:241


Could you enter a PR?
 http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?user=guest&password=guest&database=java&cmd=login

thanks

  [ bryce ]


^ permalink raw reply	[flat|nested] 10+ messages in thread

* PR libgcj/184 [was Re: Re: Some null pointer method invocations causes segmentation fault]
  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
  1 sibling, 0 replies; 10+ messages in thread
From: Bryce McKinlay @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Andrew Haley; +Cc: rolfwr, java-discuss, java-gnats

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 ]


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Some null pointer method invocations causes segmentation fault
  2000-03-27 14:52 Some null pointer method invocations causes segmentation fault Rolf W. Rasmussen
  2000-03-27 16:21 ` Bryce McKinlay
@ 2000-04-01  0:00 ` Rolf W. Rasmussen
  1 sibling, 0 replies; 10+ messages in thread
From: Rolf W. Rasmussen @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

The following program causes a segmentation fault when run, instead of
the NullPointerException one would expect.

--------
public class NullPointerExceptionTest {
    public static void main(String[] args) {
        ((Integer) null).intValue();
    }
}
--------

Starting
program: /home/debian/rolfwr/prg/testgcj/./NullPointerExceptionTest

[...]
Program received signal SIGSEGV, Segmentation fault.
0x400dfef9 in java.lang.Integer.intValue (this=null)
    at ../../../libjava/java/lang/Integer.java:60
60          return value;
Current language:  auto; currently java
(gdb) bt
#0  0x400dfef9 in java.lang.Integer.intValue (this=null)
    at ../../../libjava/java/lang/Integer.java:60
#1  0x804af63 in NullPointerExceptionTest.main (args=@8081ff0)
    at NullPointerExceptionTest.java:3
#2  0x4013160a in gnu::gcj::runtime::FirstThread::run (this=@8064ea0)
[...]

Other one-liners that trigger the same problem:

    ((String) null).length();
    ((java.util.Vector) null).size();
    Boolean ref = null; ref.booleanValue();

I've compiled/run with gcj/libgcj pulled from CVS on 27. March.
gcc version 2.96 20000327 (experimental) on i586-pc-linux-gnu

--
Rolf W. Rasmussen

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Some null pointer method invocations causes segmentation fault
  2000-03-28  1:00   ` Andrew Haley
  2000-03-28 19:14     ` PR libgcj/184 [was Re: Re: Some null pointer method invocations causes segmentation fault] Bryce McKinlay
@ 2000-04-01  0:00     ` Andrew Haley
  1 sibling, 0 replies; 10+ messages in thread
From: Andrew Haley @ 2000-04-01  0:00 UTC (permalink / raw)
  To: bryce; +Cc: rolfwr, java-discuss

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2000-04-01  0:00 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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     ` 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

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