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