[Ping] Re: RFR: 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*)

[Markus Gronlund]

Hi Denghui,

Thanks for reporting. I am looking into it, also exploring if we can perhaps fix it in some way to help reduce verbosity.

Thanks
Markus 



-----Original Message-----
From: hotspot-jfr-dev <hotspot-jfr-dev-retn at openjdk.java.net> On Behalf Of Denghui Dong
Sent: den 24 februari 2021 03:53
To: hotspot-jfr-dev <hotspot-jfr-dev at openjdk.java.net>
Subject: [Ping] Re: RFR: 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*)

Ping again.

Could anyone review this fix?

This problem is really occurred in our production environment(JDK 8), so I want to fix it and backport it then.

Denghui
------------------------------------------------------------------
From:董登辉(卓昂) <denghui.ddh at alibaba-inc.com> Send Time:2021年2月15日(星期一) 22:22 To:hotspot-jfr-dev <hotspot-jfr-dev at openjdk.java.net>; hotspot-jfr-dev <hotspot-jfr-dev-retn at openjdk.java.net>
Subject:Re: RFR: 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*)

Gentle ping.

Denghui Dong
------------------------------------------------------------------
From:Denghui Dong <ddong at openjdk.java.net> Send Time:2021年2月7日(星期日) 09:30 To:hotspot-jfr-dev <hotspot-jfr-dev at openjdk.java.net>
Subject:Re: RFR: 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*)

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