Bug ID: JDK-8181110 jvmti/hotswap test crashes in Method::checked_resolve_jmethod_id(

JDK-8181110 : jvmti/hotswap test crashes in Method::checked_resolve_jmethod_id(_jmethodID*)

Type: Bug
Component: hotspot
Sub-Component: jvmti
Affected Version: 9,16,17,18

Priority: P3
Status: Resolved
Resolution: Duplicate

Submitted: 2017-05-25
Updated: 2022-11-07
Resolved: 2022-11-07

Related Reports

Duplicate :	JDK-8245877 - assert(_value != __null) failed: resolving NULL _value in JvmtiExport::post_compiled_method_load
Relates :	JDK-8235829 - graal crashes with Zombie.java test
Relates :	JDK-8173361 - various crashes in JvmtiExport::post_compiled_method_load
Relates :	JDK-8212160 - JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value"
Relates :	JDK-8213466 - Method::checked_resolve_jmethod_id() could do better checks
Relates :	JDK-8268524 - nmethod::post_compiled_method_load_event racingly called on zombie
Relates :	JDK-8227410 - jvmti/scenarios/hotswap/HS101/hs101t005 crashes with SIGSEGV
Relates :	JDK-8245877 - assert(_value != __null) failed: resolving NULL _value in JvmtiExport::post_compiled_method_load

Description

;; Using jvm: "/scratch/home/aginfra/CommonData/TEST_JAVA_HOME/lib/server/libjvm.so"
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f11ca2c23ae, pid=4661, tid=4684
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (fastdebug build 9-internal+0-2017-05-19-165053.jesper.dev2397-hs)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 9-internal+0-2017-05-19-165053.jesper.dev2397-hs, compiled mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x12953ae]  Method::checked_resolve_jmethod_id(_jmethodID*)+0xe
#
# Core dump will be written. Default location: /scratch/home/aginfra/sandbox/results/ResultDir/hs101t006/core.4661
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line: -Xcomp -Xcomp -XX:MaxRAMFraction=8 -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -XX:+TieredCompilation -XX:+IgnoreUnrecognizedVMOptions -XX:+AggressiveOpts -XX:-UseBiasedLocking -Xss2m -agentlib:HotSwap=-waittime=5 package=nsk samples=100 mode=mixed bci=call nsk.jvmti.scenarios.hotswap.HS101.hs101t006

Host: spb23587.ru.oracle.com, Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 2 cores, 10G, Oracle Linux Server release 7.0
Time: Sat May 20 22:34:45 2017 EDT elapsed time: 91 seconds (0d 0h 1m 31s)

---------------  T H R E A D  ---------------

Current thread (0x00007f11c434e9d0):  JavaThread "Service Thread" daemon [_thread_in_vm, id=4684, stack(0x00007f11734d4000,0x00007f11736d5000)]

Stack: [0x00007f11734d4000,0x00007f11736d5000],  sp=0x00007f11736d3a60,  free space=2046k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x12953ae]  Method::checked_resolve_jmethod_id(_jmethodID*)+0xe;;  Method::checked_resolve_jmethod_id(_jmethodID*)+0xe
V  [libjvm.so+0xff5228]  jvmti_GetMethodName+0x258;;  jvmti_GetMethodName+0x258
C  [libHotSwap.so+0xe15d]  CompiledMethodLoad+0x8d;;  CompiledMethodLoad+0x8d
V  [libjvm.so+0x1089e32]  JvmtiExport::post_compiled_method_load(nmethod*)+0x282;;  JvmtiExport::post_compiled_method_load(nmethod*)+0x282
V  [libjvm.so+0x109b424]  JvmtiDeferredEvent::post()+0x74;;  JvmtiDeferredEvent::post()+0x74
V  [libjvm.so+0x14dfad0]  ServiceThread::service_thread_entry(JavaThread*, Thread*)+0x490;;  ServiceThread::service_thread_entry(JavaThread*, Thread*)+0x490
V  [libjvm.so+0x161f95e]  JavaThread::thread_main_inner()+0x22e;;  JavaThread::thread_main_inner()+0x22e
V  [libjvm.so+0x161fbee]  JavaThread::run()+0x1ce;;  JavaThread::run()+0x1ce
V  [libjvm.so+0x136e4b2]  thread_native_entry(Thread*)+0x112;;  thread_native_entry(Thread*)+0x112
C  [libpthread.so.0+0x7dc5]  start_thread+0xc5

Comments

After a number of fixes in the area there are no new failures for almost a year. Closing as a dup of JDK-8245877
07-11-2022
Coleen posted the following comment in the bug JDK-8227410: > This problem and the one in JDK-8181110 could have been fixed with JDK-8245877 and/or JDK-8268524. I've just closed JDK-8227410 as a dup of JDK-8245877. We could also consider to close this one as well. I leave this decision up to Alex though.
02-07-2022
Here's the crashing thread's stack for the jdk-18+24-1605-tier4 sighting: --------------- T H R E A D --------------- Current thread (0x00007efeb82c8540): JavaThread "Service Thread" daemon [_thread_in_vm, id=1068008, stack(0x00007efe9cd9f000,0x00007efe9cfa0000)] Stack: [0x00007efe9cd9f000,0x00007efe9cfa0000], sp=0x00007efe9cf9e970, free space=2046k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x14f7373] Method::checked_resolve_jmethod_id(_jmethodID)+0x13 V [libjvm.so+0x11c5122] jvmti_GetMethodName+0x192 C [libHotSwap.so+0xc44f] CompiledMethodLoad+0x6f V [libjvm.so+0x125cca8] JvmtiExport::post_compiled_method_load(JvmtiEnv, nmethod)+0x278 V [libjvm.so+0x125d02b] JvmtiExport::post_compiled_method_load(nmethod)+0xab V [libjvm.so+0x177b0d7] ServiceThread::service_thread_entry(JavaThread, JavaThread)+0x8a7 V [libjvm.so+0x19143fa] JavaThread::thread_main_inner()+0x25a V [libjvm.so+0x191c7c0] Thread::call_run()+0x100 V [libjvm.so+0x15fe964] thread_native_entry(Thread*)+0x104 siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr: 0x0000000000000000
17-11-2021
It'd be nice to address this in 18.
24-08-2021
I was not able to reproduce the issue. Looks like a race. Not clear if a fix similar to JDK-8161144 can solve the issue. Maybe it can fix the crash, but the test will fail anyway because GetMethodName will return error. So the problem is more general - CompiledMethodLoad is called with invalid methodID
04-03-2021
Closing issue as not reproducible. Please reopen the issue if it happens again.
12-10-2020
Based on the comments for JDK-8147451 there were 2 problems spotted: 1) clear_all_methods() does not walk all the linked JNIMethodBlock-s 2) Method::deallocate_contents() should clear 'this' from list of Methods in JNIMethodBlock JDK-8147451 addressed only first problem (in JDK9+ this first problem is fixed in JDK-8062116) and the fix failed. The follow-up issue was filed for JDK8 JDK-8161144 that addressed the second problem in Method::deallocate_contents(). Review thread for JDK-8147451 : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-June/019793.html Review threads for JDK-8161144 : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-July/020449.html and http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-August/020509.html
30-07-2020
Issue has been seen once. Possible transient environmental issue. Closing as CNR.
02-10-2017
Of course, this bug is different than 8164563. It is about compiled method load events, not unload. But it requires using the JvmtiDeferredEvent helper class as used for unload. I wonder, if there can be similar problems related to events deferring.
31-05-2017
this failure happened in JDK 9 testing, JDK-8164563 is fixed only in JDK 10.
30-05-2017
I wonder if this bug can be anyhow related or similar to the one that was recently fixed by Chris: https://bugs.openjdk.java.net/browse/JDK-8164563
25-05-2017
Attached the full hs_err log.
25-05-2017