JDK-4292742 : NullPointerException with no stack trace
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.0,1.4.1,1.4.2,1.4.2_11,5.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    generic,linux,solaris_2.6,solaris_9,windows_2000 generic,linux,solaris_2.6,solaris_9,windows_2000
  • CPU: generic,x86,sparc
  • Submitted: 1999-11-18
  • Updated: 2021-09-06
  • Resolved: 2004-11-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other
1.3.1_14 b01Fixed 1.4.2_05Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
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
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
02-10-2004

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
13-08-2004

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
04-03-2004

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
21-10-2003