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

[David M. Lloyd]

On 11/14/2016 11:07 AM, David M. Lloyd wrote:
> On 11/14/2016 11:02 AM, David M. Lloyd wrote:
>> On 11/14/2016 09:54 AM, David M. Lloyd wrote:
>>> On 11/14/2016 09:39 AM, Chris Hegarty wrote:
>>>>
>>>> On 14/11/16 15:29, Andrew Haley wrote:
>>>>> On 14/11/16 14:47, David M. Lloyd wrote:
>>>>>
>>>>>> 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.
>>>>>
>>>>> java.net.NetworkInterface.getAll() will return null if it fails to
>>>>> create an instance of NetworkInterface.  It's quite possible that
>>>>> inlining will make it appear that a NPE at getAll's caller is reported
>>>>> at the return.
>>>>>
>>>>> Try either TieredStopAtLevel=1 or disable compilation for getAll().
>>>>
>>>> Additionally, is it possible to run with '-Xcheck:jni' ?
>>>
>>> We'll give it a shot.
>>
>> We're having a hard time getting JVM arguments set in all the processes
>> of the test suite; we're working on that, but in the mean time, some
>> more possibly related problems came up (and maybe this is starting to
>> move into a hotspot-dev category?)...
>>
>> Now we're seeing NPEs originating at odd places, like one of these three
>> instructions:
>>
>>        0: aload_0
>>        1: invokestatic  #10                 // Method
>> doInject:(Lorg/jboss/msc/service/ValueInjection;)V
>>        4: return
>>
>> None of which should possibly be able to trigger an NPE... right? Unless
>> it's some kind of unexpected SIGSEGV that looks sufficiently like a null
>> dereference...?
>>
>> So maybe JNI isn't actually a factor.  Or maybe Andrew's inline idea has
>> some runway to it.
>
> Here's another:
>
>       87: aload_0
>       88: aload         7
>       90: putfield      #17                 // Field
> extensionModuleName:Ljava/lang/String;
> ...
>    LocalVariableTable:
>       Start  Length  Slot  Name   Signature
>           0      94     0  this
> Lorg/jboss/as/controller/extension/ExtensionRegistry$SubsystemRegistrationImpl;
>
>
> If "this" is null, then something bad is happening, right?

Adding -XX:TieredStopAtLevel=1 appears to fix the problem.  I'll move 
this over to hotspot-dev I guess... with any luck, it's something that 
was already fixed.

-- 
- DML