NPE on "return" bytecode of java.net.NetworkInterface

Langer, Christoph christoph.langer at sap.com
Mon Nov 14 15:29:00 UTC 2016


Hi David,

can this be reproduced?

What platform is it about? There have been fixes for some Windows native coding lately: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/ef9b2921bfa5

It really looks like some issues in the native code with a misleading callstack.

Best regards
Christoph



> -----Original Message-----
> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf
> Of David M. Lloyd
> Sent: Montag, 14. November 2016 15:48
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: NPE on "return" bytecode of java.net.NetworkInterface
> 
> I'm trying to work out something a colleague has observed during testing
> on an OpenJDK based on 1.8.0_111 (build 1.8.0_111-b16).
> 
> The business end of the stack trace looks like this:
> 
> 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)
> 
> According to javap, line 80 corresponds exclusively to the "return"
> instruction of the constructor:
> 
>    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
> 
> Since this method is called from a native method, is it possible that
> somehow the native method is generating an NPE, but the Java method is
> still in the stack context?  I assume that what is happening here is
> some kind of class init order snafu, but it's pretty tricky to diagnose
> exactly with this non-intuitive stack.
> 
> --
> - DML


More information about the core-libs-dev mailing list