United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4292742 : NullPointerException with no stack trace

Details
Type:
Enhancement
Submit Date:
1999-11-18
Status:
Resolved
Updated Date:
2004-11-21
Project Name:
JDK
Resolved Date:
2004-11-21
Component:
hotspot
OS:
solaris_9,solaris_2.6,linux,generic,windows_2000
Sub-Component:
compiler
CPU:
x86,sparc,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.0,1.4.1,1.4.2,1.4.2_11,5.0
Fixed Versions:
1.3.1_14 (b01)

Related Reports
Backport:
Backport:
Duplicate:
Duplicate:
Duplicate:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
Subject: minor buglet
Date: Wed, 17 Nov 1999 17:44:17 PST
From: Tom Rodriguez <###@###.###>
Organization: Xerox PARC
To: Steffen Grarup <###@###.###>

Occasionally I get exceptions like this from hotspot:

8 C:/projects # java test
Exception in thread "main" java.lang.NullPointerException
        <<no stack trace available>>

which should look like this:

9 C:/projects # java -Xint test
Exception in thread "main" java.lang.NullPointerException
        at java.lang.System.arraycopy(Native Method)
        at test.t(test.java:17)
        at test.main(test.java:10)

It seems like once code is compiled you can't get accurate backtraces
from System.arraycopy, which is quite annoying.  This seems to be a bug
only in the server VM.  The client VM doesn't have this problem.  Here's
a test program for it.  Just an FYI.

tom

public class test {
    static Object[] src = new Object[10];
    static Object[] dest1 = new Object[10];
    static Object[] dest2 = null;

    static int count = 100000;

    public static void main(String[] args) {
        t(false);
        t(true);
    }

    public static void t(boolean n) {
        for (int i = 0; i < count; i++) {
            if (n && (i + 1 == count))
                System.arraycopy(src, 0, dest2, 0, src.length);
            else
                System.arraycopy(src, 0, dest1, 0, src.length);
        }
    }
}
==========================================================================

This issue still happens with 1.4.1-beta-b12.

The following messages are the result when we tried the above attached 
program with windows2000(SP2).

M:\shares\no-trace-server>java test
Exception in thread "main" java.lang.NullPointerException
        at java.lang.System.arraycopy(Native Method)
        at test.t(test.java:16)
        at test.main(test.java:10)

M:\shares\no-trace-server>java -Xint test
Exception in thread "main" java.lang.NullPointerException
        at java.lang.System.arraycopy(Native Method)
        at test.t(test.java:16)
        at test.main(test.java:10)

M:\shares\no-trace-server>java -server test
Exception in thread "main" java.lang.NullPointerException

This is very inconvenient. Even if some error occurs, the licensee can not
do anything.
There might be the following opinion,
 "when debugging, use -client(default) first and debug all errors.
  After debugging, apply the application to he real system with -server 
  option."
However, the server VM is very different from the client VM.
There is the error which happens only with server option.
Against such error, they can not do anything....

Please reconsider to add the trace feature to -sever option
and look at their comment in "COMMENT"

2002-05-22
==========================================================================

                                    

Comments
SUGGESTED FIX

The simplest fix to this problem is to have do_athrow
always make an uncommon trap, except in the case of Deopt_athrow.

This makes NPE and DIV0 exceptions work the same way as
range checks and failed casts.

The objections are:
 - It increases server compilation time (10%).
 - It may introduce a performance pothole we had been skirting.

I am looking at ways to reduce the compilation time by pruning
the JVM of the uncommon trap to a bare minimum.

The performance pothole can be reduced, perhaps, by using the
preallocated exception instances in cases where the backtrace
does not escape.  This requires tricky analysis.

###@###.### 2003-10-21

I have attached a patch file suggesting a simple fix for the mantis source base.
It has not been tested.

###@###.### 2003-11-25
                                     
2003-10-21
EVALUATION

Problem understood by c2 team - right now, no attempt is made to get the
stack trace.  This isn't a high priority item, only of issue
for debugging.

david.stoutamire@Eng 2000-02-03

Will not fix

azeem.jiva@Eng 2001-05-21

Will attempt to fix in 1.5.0.
###@###.### 2004-02-06

Fixed by reworking the "built-in" exception processing.
Now all cold exceptions (first few times) are handled by
uncommon traps.  After recompilation, the compiler may
choose the older, faster tactic, under control of the
switch -XX:+OmitStackTraceInFastThrow (default true).

The fix applies the same technique uniformly to all Java
bytecode traps, including NPE, RCE, DIV0, and casts.

###@###.### 2004-03-04
                                     
2004-03-04
WORK AROUND

This problem should be very rare or nonexistent starting with 1.5 Hotspot.

If the bug recurs in 1.5 Hotspot, use the flag -XX:-OmitStackTraceInFastThrow as a workaround.

In recent updates of the 1.4.2 VM (_05), use the flag -XX:+FullSpeedJVMDI, even without jvmdi turned on.  This may make compilation performance suffer, so it is not the default.

###@###.### 2004-08-13
                                     
2004-08-13
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
1.3.1_14
1.4.2_05
generic
tiger-beta2

FIXED IN:
1.3.1_14
1.4.2_05
tiger-beta2

INTEGRATED IN:
1.3.1_14
1.4.2_05
tiger-beta2

VERIFIED IN:
1.4.2_05


                                     
2004-10-02



Hardware and Software, Engineered to Work Together