Arbitrary JVM Behaviour

Question

Imagine a setup of 6-7 servers all identical with identical java version "1.6.0_18" OpenJDK Runtime Environment (IcedTea6 1.8) (fedora-36.b18.fc11-i386) OpenJDK Server VM (build 14.0-b16, mixed mode)

each running a program (memory and CPU intensive) for hours even days, completing successfully many times (getting statistical data that sort of stuff), but on 1 machine, no matter the parameters or how I've complied (javac -source 1.5 .java/javac -O -source 1.5, javac *, imagine any combination yourself :))
or ran it (-Xms200000k or just java blabla.java you get the idea)

I eventually get, not at a specific moment or iteration "java.lang.ArrayIndexOutOfBoundsException: -1341472392" ?! 1st things first the program would never work with such a large value, let alone negative. (the line of code is a contains call of an ArrayList with integers) (that number is different every time as i've noticed)

Note also that i can "resume" a crashed test and i can on this machine, it does few more tests, crashes again.

Not much of a bother, I dont own the boxes and all the others work, but this is quite strange for me.

Out of personal interest how this happens on the not-very-rosy-anyway OpenJDK?

Answer 1

Sounds strange. Is the variable used for indexing the array a long, or is it ever influenced by a long-variable? In that case the access to the variable is not guaranteed to be atomic:

From http://java.sun.com/docs/books/jls/second_edition/html/memory.doc.html#28733

If a double or long variable is not declared volatile, then for the purposes of load, store, read, and write actions they are treated as if they were two variables of 32 bits each: wherever the rules require one of these actions, two such actions are performed, one for each 32-bit half. The manner in which the 64 bits of a double or long variable are encoded into two 32-bit quantities is implementation-dependent. The load, store, read, and write actions on volatile variables are atomic, even if the type of the variable is double or long.

You could try to declare the index-variable as volatile or use some other means of synchronization (for instance by using AtomicLong or something similar) if you suspect that this could be the issue.

Answer 2

If this is a single-threaded Java application, I'd suspect a hardware fault. Of course this could be hard to prove, unless you've got someway to run hardware (e.g. memory) diagnostics.