8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) #2295

D-D-H · 2021-01-28T16:55:41Z

hi,

Could I have a review of this fix?

If we run the following code snippet, will get a crash

class JFRDemo {
    public static void main(String[] args) {
        Recording r = new Recording();
        r.enable("MyEvent");
        r.start();

        MyEvent event = new MyEvent();
        event.begin();
        event.clazz = long.class;
        event.commit();
    }
}

class MyEvent extends Event {

    @Label("Class")
    public Class clazz;
}

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*)

Download

$ git fetch https://git.openjdk.java.net/jdk pull/2295/head:pull/2295
$ git checkout pull/2295

bridgekeeper · 2021-01-28T16:55:54Z

👋 Welcome back ddong! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

D-D-H · 2021-01-28T16:56:45Z

/label hotspot-jfr

openjdk · 2021-01-28T16:56:58Z

@D-D-H The following label will be automatically applied to this pull request:

hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

openjdk · 2021-01-28T16:57:12Z

@D-D-H
The hotspot-jfr label was successfully added.

mlbridge · 2021-01-28T17:01:51Z

Webrevs

D-D-H · 2021-01-29T05:44:42Z

/label remove hotspot

openjdk · 2021-01-29T05:44:58Z

@D-D-H
The hotspot label was successfully removed.

D-D-H · 2021-01-31T13:30:43Z

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.

D-D-H · 2021-02-02T15:06:14Z

JVM.getClassId() doesn't seem to be used, so I didn't modify the implementation of the corresponding intrinsics.

D-D-H · 2021-02-07T01:27:31Z

Gentle ping.

mlbridge · 2021-02-15T14:23:40Z

Mailing list message from Denghui Dong on hotspot-jfr-dev:

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

mlbridge · 2021-02-24T02:54:40Z

Mailing list message from Denghui Dong on hotspot-jfr-dev:

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

mlbridge · 2021-02-25T12:17:39Z

Mailing list message from Markus Gronlund on hotspot-jfr-dev:

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

D-D-H · 2021-03-01T07:56:50Z

another PR(#2738) is created for the same issue.

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

d2d7477

openjdk bot added the rfr Pull request is ready for review label Jan 28, 2021

openjdk bot added hotspot hotspot-dev@openjdk.org hotspot-jfr hotspot-jfr-dev@openjdk.org labels Jan 28, 2021

clean doc

0ba1623

openjdk bot removed the hotspot hotspot-dev@openjdk.org label Jan 29, 2021

improve patch

811690c

D-D-H added 2 commits February 5, 2021 10:40

Amend copyright

7ea82d4

Amend test

736f268

D-D-H closed this Mar 1, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) #2295

8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) #2295

D-D-H commented Jan 28, 2021 •

edited by openjdk bot

bridgekeeper bot commented Jan 28, 2021

D-D-H commented Jan 28, 2021

openjdk bot commented Jan 28, 2021

openjdk bot commented Jan 28, 2021

mlbridge bot commented Jan 28, 2021 •

edited

D-D-H commented Jan 29, 2021

openjdk bot commented Jan 29, 2021

D-D-H commented Jan 31, 2021

D-D-H commented Feb 2, 2021

D-D-H commented Feb 7, 2021

mlbridge bot commented Feb 15, 2021

mlbridge bot commented Feb 24, 2021

mlbridge bot commented Feb 25, 2021

D-D-H commented Mar 1, 2021

8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) #2295

8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*) #2295

Conversation

D-D-H commented Jan 28, 2021 • edited by openjdk bot

Progress

Issue

Download

bridgekeeper bot commented Jan 28, 2021

D-D-H commented Jan 28, 2021

openjdk bot commented Jan 28, 2021

openjdk bot commented Jan 28, 2021

mlbridge bot commented Jan 28, 2021 • edited

Webrevs

D-D-H commented Jan 29, 2021

openjdk bot commented Jan 29, 2021

D-D-H commented Jan 31, 2021

D-D-H commented Feb 2, 2021

D-D-H commented Feb 7, 2021

mlbridge bot commented Feb 15, 2021

mlbridge bot commented Feb 24, 2021

mlbridge bot commented Feb 25, 2021

D-D-H commented Mar 1, 2021

D-D-H commented Jan 28, 2021 •

edited by openjdk bot

mlbridge bot commented Jan 28, 2021 •

edited