Looking further into this the crash occurs because java.lang.Class has not been initialized yet. Logging shows we go straight from initializing Object to initializing java.net.Authenticator then to java.lang.invoke.MethodHandleNatives.

[3.484s][debug][vtables ] Initializing: java/lang/invoke/MethodHandleNatives
[3.484s][trace][vtables ] copy vtable from java.lang.Object to java.lang.invoke.MethodHandleNatives size 5 [3.484s][info ][class,init ] 2 Initializing 'java/lang/invoke/MethodHandleNatives' (0x000000080000c608) [3.485s][debug][class,resolve ] java.lang.invoke.MethodHandleNatives java.lang.Class MethodHandleNatives.java:44 [3.485s][trace][vtables ] invokevirtual resolved method: caller-class:java.lang.invoke.MethodHandleNatives, compile-time-class:java.lang.Class, method:java.lang.Class.desiredAssertionStatus()Z, method_holder:java.lang.Class, access_flags: public
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc: SuppressErrorAt=/linkResolver.cpp:1295

But why we are not implicitly initializing java.lang.Class before the invokevirtual processing?

The clinit for MethodHandleNatives starts with:

 static {};
    descriptor: ()V
    flags: (0x0008) ACC_STATIC
    Code:
      stack=3, locals=2, args_size=0
         0: ldc #160 // class java/lang/invoke/MethodHandleNatives
2: invokevirtual #161 // Method java/lang/Class.desiredAssertionStatus:()Z

A class must be initialized before we may invoke a method on it, or obtain an instance - so why is nothing ensuring java.lang.Class is initialized?

David
-----

On 4/01/2017 1:11 PM, David Holmes wrote:
We have encountered a crash in a JVM TI test, starting with b148, that
is caused by the attempted use of MethodRefs and invoke_dynamic within
class loading that occurs from the "early VM start" JVM TI event
callback - which happens before the VM and core classes are fully
initialized. The class being loaded/initialized is in java.base and so
this is allowed. The class, java.net.Authenticator, was changed in b148
to have static initialization involving method refs and hence the
problem was introduced.

I've included a stack dump below.

It is far from clear to me where responsibility for this lies, or even
how to narrow that down. Is it in the code of MethodHandleNatives? Or is
it in the VM linking/resolution code?

Thoughts appreciated. :)

Thanks,
David
-----


--------------- T H R E A D ---------------

Current thread (0x00007ff99c01c000): JavaThread "Unknown thread"
[_thread_in_vm, id=31105, stack(0x00007ff9a5584000,0x00007ff9a5684000)]

Stack: [0x00007ff9a5584000,0x00007ff9a5684000], sp=0x00007ff9a56809e0,
free space=1010k
Native frames: (J=compiled Java code, A=aot compiled Java code,
j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x16b1932] VMError::report_and_die(int, char const*, char
const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char cons
t*, int, unsigned long)+0x162
V [libjvm.so+0x16b26af] VMError::report_and_die(Thread*, char const*,
int, char const*, char const*, __va_list_tag*)+0x2f
V [libjvm.so+0xaa0fed] report_vm_error(char const*, int, char const*,
char const*, ...)+0xdd
V [libjvm.so+0x110fbd6]
LinkResolver::runtime_resolve_virtual_method(CallInfo&, methodHandle
const&, KlassHandle, Handle, KlassHandle, bool, Th
read*)+0x1f6
V [libjvm.so+0x11128b5] LinkResolver::resolve_invokevirtual(CallInfo&,
Handle, constantPoolHandle const&, int, Thread*)+0x185
V [libjvm.so+0x1113c5b] LinkResolver::resolve_invoke(CallInfo&, Handle,
constantPoolHandle const&, int, Bytecodes::Code, Thread*)+0xab
V [libjvm.so+0xdea7da] InterpreterRuntime::resolve_invoke(JavaThread*,
Bytecodes::Code)+0x23a
V [libjvm.so+0xdf69bb]
InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0xeb
j java.lang.invoke.MethodHandleNatives.<clinit>()V+2 java.base
v ~StubRoutines::call_stub
V [libjvm.so+0xe15970] JavaCalls::call_helper(JavaValue*, methodHandle
const&, JavaCallArguments*, Thread*)+0x950
V [libjvm.so+0xdcd15c]
InstanceKlass::call_class_initializer_impl(instanceKlassHandle,
Thread*)+0x15c
V [libjvm.so+0xdcd2a3] InstanceKlass::call_class_initializer(Thread*)+0x83
V [libjvm.so+0xdcd762]
InstanceKlass::initialize_impl(instanceKlassHandle, Thread*) [clone
.part.160]+0x4a2
V [libjvm.so+0xdcdd2b]
InstanceKlass::initialize_impl(instanceKlassHandle, Thread*)+0x13b
V [libjvm.so+0xdcde72] InstanceKlass::initialize(Thread*)+0x102
V [libjvm.so+0x110dd0c] LinkResolver::resolve_static_call(CallInfo&,
LinkInfo const&, bool, Thread*)+0x14c
V [libjvm.so+0xe13e3a] JavaCalls::call_static(JavaValue*, KlassHandle,
Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x13a
V [libjvm.so+0x15bd833]
SystemDictionary::find_method_handle_type(Symbol*, KlassHandle,
Thread*)+0x10f3
V [libjvm.so+0x15be1c6]
SystemDictionary::link_method_handle_constant(KlassHandle, int,
KlassHandle, Symbol*, Symbol*, Thread*)+0x596
V [libjvm.so+0xa8ad46]
ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int,
int, Thread*)+0x7d6
V [libjvm.so+0xa8b7ad]
ConstantPool::resolve_bootstrap_specifier_at_impl(constantPoolHandle
const&, int, Thread*)+0x16d
V [libjvm.so+0x11135db] LinkResolver::resolve_invokedynamic(CallInfo&,
constantPoolHandle const&, int, Thread*)+0x71b
V [libjvm.so+0x1113d2e] LinkResolver::resolve_invoke(CallInfo&, Handle,
constantPoolHandle const&, int, Bytecodes::Code, Thread*)+0x17e
V [libjvm.so+0xdebb64]
InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x274
V [libjvm.so+0xdf69a8]
InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0xd8
j java.net.Authenticator.<clinit>()V+0 java.base
v ~StubRoutines::call_stub
V [libjvm.so+0xe15970] JavaCalls::call_helper(JavaValue*, methodHandle
const&, JavaCallArguments*, Thread*)+0x950
V [libjvm.so+0xdcd15c]
InstanceKlass::call_class_initializer_impl(instanceKlassHandle,
Thread*)+0x15c
V [libjvm.so+0xdcd2a3] InstanceKlass::call_class_initializer(Thread*)+0x83
V [libjvm.so+0xdcd762]
InstanceKlass::initialize_impl(instanceKlassHandle, Thread*) [clone
.part.160]+0x4a2
V [libjvm.so+0xdcdd2b]
InstanceKlass::initialize_impl(instanceKlassHandle, Thread*)+0x13b
V [libjvm.so+0xdcde72] InstanceKlass::initialize(Thread*)+0x102
V [libjvm.so+0xf331f2] find_class_from_class_loader(JNIEnv_*, Symbol*,
unsigned char, Handle, Handle, unsigned char, Thread*)+0x122
V [libjvm.so+0xec0369] jni_FindClass+0x5e9
C [libjckjvmti.so+0x60d69] vmse00101_VMStart+0x2b
V [libjvm.so+0x107ce3b] JvmtiExport::post_early_vm_start()+0xcb
V [libjvm.so+0x16150ee] Threads::create_vm(JavaVMInitArgs*, bool*)+0x4de

Reply via email to