Subject: minor buglet
Date: Wed, 17 Nov 1999 17:44:17 PST

Organization:  customer  PARC


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

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.

  xxxxx@xxxxx   2004-08-13

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.

  xxxxx@xxxxx   2000-02-03

Will not fix

  xxxxx@xxxxx   2001-05-21

Will attempt to fix in 1.5.0.
  xxxxx@xxxxx   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.

  xxxxx@xxxxx   2004-03-04

This is a high priority issue! Our Java program fails once or 
twice a day with this error - without any clue where to 
search for it in over 600 classes plus external libraries.

I support ge.schroeder's point, but I guess his problem is
releated to bug  4761344

I can confirm that we are still seeing this error in JDK 1.4.2 in 
2003.  I cannot believe the evaluation of this!!  My 
god.  "only of issue for debugging"?!?  Only of issue if you 
need working code?  This is why Java has exceptions, to 
promote working code.

I am getting a little tired by some of the Sun's engineers evaluations.  Not a 
high priority? What the...?

In a production environment, how are we supposed to diagnose what the frick 
is going on?  Don't use the server VM? You might as well tell us to not to 
drive in 5th gear.

Geez.  Where's the support.

Not high priority?! While our server throw such exception,we 
could do nothing because we couldn't confirm what really 
happened.When will it be fixed?

I disagree that this is an enhancement. How can you expect
to support a production environment without a stack trace?

I have received an e-mail informing me that this bug is 
fixed.  Nothing here tells me that it is, so it still gets my 
vote.

I still get the same error. I cannot understand why the bug is closed?!
I'm using linux RedHat 8.0 2.4.20-28.8 and JDK

java version "1.4.2_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04)
Java HotSpot(TM) Server VM (build 1.4.2_05-b04, mixed mode)

I did not understand any thing about the switch -XX:+OmitStackTraceInFastThrow
My JDK says Unrecognized VM option '+OmitStackTraceInFastThrow'

I also cant believe it. Forget J2EE for mission critical applications ...

I am seeing this as well, but I don't call System.arraycopy().. this is with some old code that used Hashtables.. could a Hashtable rehash also cause this?

It seems that this bug effectively makes the "Server" VM unusable for production. Why is it an "enhancement"?

Still occurs in 1.4.2_05

Still occurs in 1.4.2_05

Still occurs in 1.4.2_05

Still occurs in 1.4.2_05 !

Still occurs in 1.4.2_05 !

Still happens with 1.4.2_05

Still happens with 1.4.2_05

Still happens with 1.4.2_05

Sorry, for the last double posts, but I just get an error page (404) after submitting the comment. So I retried it again until i saw that the comments were posted. It seems that the confirmation page of such a post is broken.

I just ran into this problem with JDK 1.4.2_05 on Red Hat Linux 7.2 2.96-116.7.2. And it

I am seeing it in a different place now (though I can't narrow it down).. I'm using Red Hat Linux release 7.3 (Valhalla).

Any idea what the ETA on fixing this bug is.. Im at 1.4.2_05 and have no idea how Im going to debug this production problem
Thanks