Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 5 commits into from

Conversation

@D-D-H
Copy link
Contributor

@D-D-H D-D-H commented Jan 28, 2021

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
Copy link

@bridgekeeper bridgekeeper bot commented Jan 28, 2021

👋 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.

Loading

@openjdk openjdk bot added the rfr label Jan 28, 2021
@D-D-H
Copy link
Contributor Author

@D-D-H D-D-H commented Jan 28, 2021

/label hotspot-jfr

Loading

@openjdk
Copy link

@openjdk openjdk bot commented Jan 28, 2021

@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.

Loading

@openjdk
Copy link

@openjdk openjdk bot commented Jan 28, 2021

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

Loading

@mlbridge
Copy link

@mlbridge mlbridge bot commented Jan 28, 2021

Loading

@D-D-H
Copy link
Contributor Author

@D-D-H D-D-H commented Jan 29, 2021

/label remove hotspot

Loading

@openjdk openjdk bot removed the hotspot label Jan 29, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Jan 29, 2021

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

Loading

@D-D-H
Copy link
Contributor Author

@D-D-H D-D-H commented Jan 31, 2021

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.

Loading

@D-D-H
Copy link
Contributor Author

@D-D-H D-D-H commented Feb 2, 2021

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

Loading

@D-D-H
Copy link
Contributor Author

@D-D-H D-D-H commented Feb 7, 2021

Gentle ping.

Loading

@mlbridge
Copy link

@mlbridge mlbridge bot commented Feb 15, 2021

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

Loading

@mlbridge
Copy link

@mlbridge mlbridge bot commented Feb 24, 2021

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

Loading

@mlbridge
Copy link

@mlbridge mlbridge bot commented Feb 25, 2021

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

Loading

@D-D-H
Copy link
Contributor Author

@D-D-H D-D-H commented Mar 1, 2021

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

Loading

@D-D-H D-D-H closed this Mar 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
1 participant