JVM crash by creating VarHandle
Ty Young
youngty1997 at gmail.com
Sat Feb 1 12:31:06 UTC 2020
Under some strange circumstances, creating a VarHandle fails with:
[libjvm.so+0xbae244] ProtectionDomainEntry::object_no_keepalive()+0x4
with the following frames:
V [libjvm.so+0xbae244] ProtectionDomainEntry::object_no_keepalive()+0x4
V [libjvm.so+0xddef71]
SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle,
Handle, Thread*)+0x191
V [libjvm.so+0xde1cc9] SystemDictionary::resolve_or_fail(Symbol*,
Handle, Handle, bool, Thread*)+0x59
V [libjvm.so+0x581e98] ConstantPool::klass_ref_at(int, Thread*)+0x158
V [libjvm.so+0x9cf886] LinkInfo::LinkInfo(constantPoolHandle const&,
int, Thread*)+0x36
V [libjvm.so+0x9d5ebe] LinkResolver::resolve_invoke(CallInfo&, Handle,
constantPoolHandle const&, int, Bytecodes::Code, Thread*)+0x13e
V [libjvm.so+0x78729e] InterpreterRuntime::resolve_invoke(JavaThread*,
Bytecodes::Code)+0x16e
V [libjvm.so+0x787887]
InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x37
j
org.goliath.crosspoint.fields.NumberField.<init>(Lorg/goliath/crosspoint/interfaces/UserDefinedData;Ljdk/incubator/foreign/MemoryAddress;Ljdk/incubator/foreign/ValueLayout;)V+60
j
org.goliath.crosspoint.structs.BasicNativeStruct.getField(I)Lorg/goliath/crosspoint/interfaces/NativeField;+204
j
org.goliath.bindings.nvml.structs.nvmlProcessInfo_t.getField(I)Lorg/goliath/crosspoint/interfaces/NativeField;+5
j org.goliath.bindings.nvml.main.Test.main([Ljava/lang/String;)V+127
v ~StubRoutines::call_stub
V [libjvm.so+0x78bd6c] JavaCalls::call_helper(JavaValue*, methodHandle
const&, JavaCallArguments*, Thread*)+0x30c
V [libjvm.so+0x8125f5] jni_invoke_static(JNIEnv_*, JavaValue*,
_jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)
[clone .isra.0] [clone .constprop.0]+0x235
V [libjvm.so+0x8152c5] jni_CallStaticVoidMethod+0x155
C [libjli.so+0x55c7] JavaMain+0xcd7
C [libjli.so+0x9529] ThreadJavaMain+0x9
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j
org.goliath.crosspoint.fields.NumberField.<init>(Lorg/goliath/crosspoint/interfaces/UserDefinedData;Ljdk/incubator/foreign/MemoryAddress;Ljdk/incubator/foreign/ValueLayout;)V+60
j
org.goliath.crosspoint.structs.BasicNativeStruct.getField(I)Lorg/goliath/crosspoint/interfaces/NativeField;+204
j
org.goliath.bindings.nvml.structs.nvmlProcessInfo_t.getField(I)Lorg/goliath/crosspoint/interfaces/NativeField;+5
j org.goliath.bindings.nvml.main.Test.main([Ljava/lang/String;)V+127
v ~StubRoutines::call_stub
This is caused by calling any of the MemoryHandles static methods with
any parameters, like so:
MemoryHandles.varHandle(long.class, ByteOrder.nativeOrder());
Don't know what's going on here. If I change some code I can get some
output saying something about a "double free or corruption" in the
console. Don't know if it's relevant or not. This is all happening in
the context of struct arrays wherein the Java representation is
reconstructed in a private class within the struct's own class as there
isn't any other more elegant way of handling struct arrays in a type
safe way AFAIK.
My understanding is that VarHandles are created independent of the
MemoryAddress(s) themselves so... no idea. The MemoryAddress and layout
of the field looks 100% fine based on some console toString prints.
More information about the panama-dev
mailing list