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