RFR: 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*)

Denghui Dong ddong at openjdk.java.net
Sun Feb 7 01:30:40 UTC 2021


On Tue, 2 Feb 2021 15:06:14 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> Add some information to facilitate this issue to be reviewed more easily.
>> 
>> We will get a crash if we run the above code,, and the stack trace is as follows:
>> 
>> Stack: [0x00007fa12b2f3000,0x00007fa12b3f4000],  sp=0x00007fa12b3f2790,  free space=1021k
>> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x89d649]  JfrTraceIdLoadBarrier::load(_jclass*)+0x39
>> V  [libjvm.so+0x86090e]  jfr_class_id+0x7e
>> j  jdk.jfr.internal.JVM.getClassIdNonIntrinsic(Ljava/lang/Class;)J+0 jdk.jfr
>> j  jdk.jfr.internal.EventWriter.putClass(Ljava/lang/Class;)V+14 jdk.jfr
>> j  jdk.jfr.internal.handlers.EventHandler1699_1612098965420-78137.write(JJLjava/lang/Class;)V+35 jdk.jfr
>> j  MyEvent.commit()V+73
>> j  JFRCrashTest.main([Ljava/lang/String;)V+39
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0x82aef5]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x2d5
>> V  [libjvm.so+0x8be315]  jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) [clone .isra.0] [clone .constprop.1]+0x345
>> V  [libjvm.so+0x8c0b3f]  jni_CallStaticVoidMethod+0x12f
>> C  [libjli.so+0x4647]  JavaMain+0xd27
>> C  [libjli.so+0x8079]  ThreadJavaMain+0x9
>> 
>> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
>> j  jdk.jfr.internal.JVM.getClassIdNonIntrinsic(Ljava/lang/Class;)J+0 jdk.jfr
>> j  jdk.jfr.internal.EventWriter.putClass(Ljava/lang/Class;)V+14 jdk.jfr
>> j  jdk.jfr.internal.handlers.EventHandler1699_1612098965420-78137.write(JJLjava/lang/Class;)V+35 jdk.jfr
>> j  MyEvent.commit()V+73
>> j  JFRCrashTest.main([Ljava/lang/String;)V+39
>> v  ~StubRoutines::call_stub
>> 
>> The root cause is that basic types, including void, do not have corresponding Klass objects inside the virtual machine, so call java_lang_Class::as_Klass will return NULL and crash in JfrTraceIdLoadBarrier::load finally.
>> 
>> My solution is adding two serializers, one for the names of basic types, and one for basic types.
>> 
>> I am not sure about the setting of the class loader is right or not, I currently set it to 0 directly.
>
> JVM.getClassId() doesn't seem to be used, so I didn't modify the implementation of the corresponding intrinsics.

Gentle ping.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2295


More information about the hotspot-jfr-dev mailing list