Sporadic NPEs in compiled code
Vladimir Kozlov
vladimir.kozlov at oracle.com
Mon Nov 14 19:18:37 UTC 2016
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.
More information about the hotspot-dev
mailing list