Java: how can an impossible NullPointerException still occur? -

i've received following bug report our software:

java.lang.nullpointerexception     @ java.util.arrays.equals(unknown source)     @ our.app.ourmain(ourmain.java:13) 

this happens jre 1.7.0_45 on windows corresponding source code of arrays.equals is:

public static boolean equals(byte[] a, byte[] a2) {     if (a==a2)         return true;     if (a==null || a2==null)         return false;      int length = a.length;     if (a2.length != length)         return false;      (int i=0; i<length; i++)         if (a[i] != a2[i])             return false;      return true; } 

calling code is:

final byte[] b1 = ... // populate array final byte[] b2 = ... // populate array final boolean equal = arrays.equals(b1, b2); 

there no way nullpointerexception raised here. how can still happen? bug report can considered trustworthy.

this not intended answer, since it'll long comment...

one question hasn't been asked yet is: when did problem start appearing? after specific update of your software or out of blue? may not able track down exact date when first occured, if can correlated time whatever deliver software underwent change (e.g. bundle jre?) causing issue. methodically disect changes between known pre-error release against first error manifesting release.

if came out of blue, source of problem (as far can tell have disclosed) hidden somewhere in execution environment of software (which possibly not under direct control). jre itself, related libraries or system services, possibly specific combination of hardware , software (believe or not, apparently bios of workstation can have drastic impact: https://www.daniweb.com/hardware-and-software/microsoft-windows/windows-vista-and-windows-7-8/threads/271699).

to improve chances of getting cause of problem, need gather information in environment(s) error surfaces, , as possible (at least jre version, 32/64 bit, os; preferably installed patches, cpu model; preferably including mask set revision, motherboard model; preferably including bios version , board revision). not forget exact release or software causing issue. if userbase has homogenous environment (e.g. in large company few workstation models purchased, possibly same vendor) little details of more interest if user base heterogenous (e.g. many independent customers using wildly different configurations).

given enough data pattern should emerge (something error reports have in common, specific jre; or set of jre versions, specific workstation model etc.).

if possible have users cooperate (intentionally alter environment of machine/user experiencing issue) test out candidates. can involve installing jdk more error context, altering vm settings , on.

only rough outline, if no quick solution turns up, methodical approach produce solution in long run.