Some null pointer method invocations causes segmentation fault

Some null pointer method invocations causes segmentation fault

[Rolf W. Rasmussen]

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

Re: Some null pointer method invocations causes segmentation fault

[Bryce McKinlay]

"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 ]

Re: Some null pointer method invocations causes segmentation fault

[Andrew Haley]

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

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

[Bryce McKinlay]

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 ]

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

[Bryce McKinlay]

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 ]

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

[Bryce McKinlay]

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 ]

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

[Bryce McKinlay]

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 ]

Re: Some null pointer method invocations causes segmentation fault

[Andrew Haley]

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

Re: Some null pointer method invocations causes segmentation fault

[Bryce McKinlay]

"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 ]

Some null pointer method invocations causes segmentation fault

[Rolf W. Rasmussen]

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