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

[David M. Lloyd]

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.
-- 
- DML