Sporadic NPEs in compiled code

[Vladimir Kozlov]

Could be https://bugs.openjdk.java.net/browse/JDK-8038348

My be other related to EA issues.

First try to run with C2 only: -XX:-TieredCompialtion
Then try to switch off EA as whole: -XX:-DoEscapeAnalysis
Or just subset of EA: -XX:-OptimizePtrCompare

Also could be incorrect memory instruction scheduling (above NULL check).

You can generate hs_err file to see recent events (deoptimization, 
compilations, uncommon traps):

-XX:+UnlockDiagnosticVMOptions 
-XX:AbortVMOnException=java.lang.NullPointerException

Also build fastdebug version of JDK and run with it. To see if it hits 
some asserts.

Thanks,
Vladimir

On 11/14/16 10:11 AM, David M. Lloyd wrote:
> We observed a problem where java.net.NetworkInterface appeared to be
> throwing an NPE originating at a line of code corresponding to its
> return instruction:
>
> Caused by: java.lang.NullPointerException
>         at java.net.NetworkInterface.<init>(NetworkInterface.java:80)
>         at java.net.NetworkInterface.getAll(Native Method)
>         at
> java.net.NetworkInterface.getNetworkInterfaces(NetworkInterface.java:343)
>
> java.net.NetworkInterface();
>     Code:
>        0: aload_0
>        1: invokespecial #3                  // Method
> java/lang/Object."<init>":()V
>        4: aload_0
>        5: aconst_null
>        6: putfield      #4                  // Field
> parent:Ljava/net/NetworkInterface;
>        9: aload_0
>       10: iconst_0
>       11: putfield      #5                  // Field virtual:Z
>       14: return
>     LineNumberTable:
>       line 79: 0
>       line 50: 4
>       line 51: 9
>       line 80: 14
>
> I assumed that the problem was possibly JNI-related, because of the
> previous stack frame, however we've begun seeing the problem in other
> bits of code as well, areas like this:
>
>        0: aload_0
>        1: invokestatic  #10                 // Method
> doInject:(Lorg/jboss/msc/service/ValueInjection;)V
>        4: return
>
> or this constructor:
>
>       87: aload_0
>       88: aload         7
>       90: putfield      #17                 // Field
> extensionModuleName:Ljava/lang/String;
>
> We've started testing with -XX:TieredStopAtLevel=1 and so far it seems
> the problems have disappeared, however, it's not clear to my
> hotspot-amateur mind at all whether it's C2 that is causing this or
> whether there is a more general timing-related race condition that is
> hidden by limiting the compiler in this way.
>
> The OpenJDK version is:
>
> openjdk version "1.8.0_111"
> OpenJDK Runtime Environment (build 1.8.0_111-b16)
> OpenJDK 64-Bit Server VM (build 25.111-b16, mixed mode)
>
> It's coming out of a Fedora 24 distribution.