JDK-8222005 : ClassRedefinition crashes with: guarantee(false) failed: OLD and/or OBSOLETE method(s) found
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 11-pool-oracle,13,15
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-04-04
  • Updated: 2024-06-28
  • Resolved: 2020-06-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 15 JDK 16
11.0.25-oracleFixed 15 b27Fixed 16Fixed
Related Reports
Blocks :  
JDK-8221470 - Print methods in exception messages in java-like Syntax.
Blocks :  
JDK-8078725 - method adjustments can be done just once for all classes involved into redefinition
Relates :  
JDK-8245126 - Kitchensink fails with: assert(!method->is_old()) failed: Should not be installing old methods
Relates :  
JDK-8299727 - crash with # Problematic frame: # V [libjvm.so+0x627e6c] ConstantPoolCache::adjust_method_entries(bool*)+0x4c
Relates :  
JDK-8245128 - Kitchensink fails with: assert(destination == (address)-1 || destination == entry) failed: b) MT-unsafe modification of inline cache
Description
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (t:/workspace/open/src/hotspot/share/prims/jvmtiRedefineClasses.cpp:4282), pid=158244, tid=262900
#  guarantee(false) failed: OLD and/or OBSOLETE method(s) found
#
# JRE version: Java(TM) SE Runtime Environment (13.0) (fastdebug build 13-internal+0-2019-04-04-2151264.leonid.mesnik.ks-apps)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 13-internal+0-2019-04-04-2151264.leonid.mesnik.ks-apps, mixed mode, sharing, tiered, compressed oops, g1 gc, windows-amd64)
# Core dump will be written. Default location: T:\testoutput\test-support\jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java\scratch\0\hs_err_pid158244.mdmp
#
# 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: -XX:MaxRAMPercentage=6 -Dkitchensink.modules.additional=Instrumentation -XX:MaxRAMPercentage=50 -XX:+HeapDumpOnOutOfMemoryError -XX:+CrashOnOutOfMemoryError -Djava.net.preferIPv6Addresses=false -XX:+DisplayVMOutputToStderr -XX:+UsePerfData -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags -XX:+DisableExplicitGC -XX:+StartAttachListener -XX:NativeMemoryTracking=detail -XX:+FlightRecorder --add-exports=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED -Djava.io.tmpdir=T:\testoutput\test-support\jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java\scratch\0/java.io.tmpdir -Duser.home=T:\testoutput\test-support\jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java\scratch\0/user.home -agentpath:c:\ade\mesos\work_dir\jib-master\install\2019-04-04-2151264.leonid.mesnik.ks-apps\windows-x64-debug.test\hotspot\jtreg\native\JvmtiStressModule.dll -Xverify:all -javaagent:redefineagent.jar applications.kitchensink.process.stress.Main T:\testoutput\test-support\jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java\scratch\0\kitchensink.final.properties

Host: Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 8 cores, 60G,  Windows Server 2012 R2 , 64 bit Build 9600 (6.3.9600.17415)
Time: Thu Apr  4 23:30:17 2019 ric elapsed time: 10 seconds (0d 0h 0m 10s)

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

Current thread (0x0000000cbeb82000):  VMThread "VM Thread" [stack: 0x0000000cbf5a0000,0x0000000cbf6a0000] [id=262900]

Stack: [0x0000000cbf5a0000,0x0000000cbf6a0000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xa6a3f1]  os::platform_print_native_stack+0xf1  (os_windows_x86.cpp:369)
V  [jvm.dll+0xc67901]  VMError::report+0xea1  (vmerror.cpp:701)
V  [jvm.dll+0xc69153]  VMError::report_and_die+0x873  (vmerror.cpp:1490)
V  [jvm.dll+0xc697d4]  VMError::report_and_die+0x64  (vmerror.cpp:1288)
V  [jvm.dll+0x4f0012]  report_vm_error+0x102  (debug.cpp:264)
V  [jvm.dll+0x890a1a]  VM_RedefineClasses::CheckClass::do_klass+0x1fa  (jvmtiredefineclasses.cpp:4282)
V  [jvm.dll+0x42ee4c]  ClassLoaderData::classes_do+0x3c  (classloaderdata.cpp:320)
V  [jvm.dll+0x4322b1]  ClassLoaderDataGraph::classes_do+0xb1  (classloaderdatagraph.cpp:332)
V  [jvm.dll+0x890c78]  VM_RedefineClasses::doit+0x238  (jvmtiredefineclasses.cpp:254)
V  [jvm.dll+0xc6aabe]  VM_Operation::evaluate+0xbe  (vmoperations.cpp:68)
V  [jvm.dll+0xc6fad8]  VMThread::evaluate_operation+0xb8  (vmthread.cpp:411)
V  [jvm.dll+0xc7047d]  VMThread::loop+0x50d  (vmthread.cpp:558)
V  [jvm.dll+0xc70e83]  VMThread::run+0xc3  (vmthread.cpp:310)
V  [jvm.dll+0xc06642]  Thread::call_run+0x192  (thread.cpp:405)
V  [jvm.dll+0xa68ebe]  thread_native_entry+0x10e  (os_windows.cpp:471)
C  [ucrtbase.DLL+0x203ba]
C  [KERNEL32.DLL+0x13d2]
C  [ntdll.dll+0x154f4]
Comments
[jdk11u-fix-request] Approval Request from Martin Should get backported for parity with 11.0.25-oracle. The backport has been reviewed and tier 1-4 have passed.
27-06-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/2817 Date: 2024-06-26 14:55:22 +0000
26-06-2024
Github URL: https://github.com/openjdk/jdk/commit/2ff9f53a442a625316cb6fedd699008d68cebc15
26-06-2024
Strictly saying, this change (JDK-8222005) depends on functions introduced in JDK-8221470. Adding JDK-8221470 as a dependency.
03-06-2024
The fix has a code dependency on JDK-8078725. I am adding a respective link.
27-05-2024
Changeset: 2ff9f53a Author: Serguei Spitsyn <sspitsyn@openjdk.org> Date: 2020-06-11 05:53:33 +0000 URL: https://git.openjdk.java.net/lanai/commit/2ff9f53a
02-07-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/8ac2e6b39630 User: sspitsyn Date: 2020-06-11 05:58:48 +0000
11-06-2020
The suggested fix is: diff --git a/src/hotspot/share/prims/jvmtiRedefineClasses.cpp b/src/hotspot/share/prims/jvmtiRedefineClasses.cpp --- a/src/hotspot/share/prims/jvmtiRedefineClasses.cpp +++ b/src/hotspot/share/prims/jvmtiRedefineClasses.cpp @@ -3605,21 +3605,24 @@ // constant pool cache holds the Method*s for non-virtual // methods and for virtual, final methods. // - // Special case: if the current class being redefined, then new_cp - // has already been attached to the_class and old_cp has already - // been added as a previous version. The new_cp doesn't have any - // cached references to old methods so it doesn't need to be - // updated. We can simply start with the previous version(s) in - // that case. + // Special case: if the current class is being redefined by the current + // VM_RedefineClasses operation, then new_cp has already been attached + // to the_class and old_cp has already been added as a previous version. + // The new_cp doesn't have any cached references to old methods so it + // doesn't need to be updated and we could optimize by skipping it. + // However, the current class can be marked as being redefined by another + // VM_RedefineClasses operation which has already executed its doit_prologue + // and needs cpchache method entries adjusted. For simplicity, the cpcache + // update is done unconditionally. It should result in doing nothing for + // classes being redefined by the current VM_RedefineClasses operation. + // Method entries in the previous version(s) are adjusted as well. ConstantPoolCache* cp_cache; - if (!ik->is_being_redefined()) { - // this klass' constant pool cache may need adjustment - ConstantPool* other_cp = ik->constants(); - cp_cache = other_cp->cache(); - if (cp_cache != NULL) { - cp_cache->adjust_method_entries(&trace_name_printed); - } + // this klass' constant pool cache may need adjustment + ConstantPool* other_cp = ik->constants(); + cp_cache = other_cp->cache(); + if (cp_cache != NULL) { + cp_cache->adjust_method_entries(&trace_name_printed); } // the previous versions' constant pool caches may need adjustment
14-05-2020
Observed a little bit different crash: # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00001475154a276c, pid=7157, tid=7167 # # JRE version: Java(TM) SE Runtime Environment (15.0) (fastdebug build 15-internal+0-2020-05-12-1648117.sspitsyn...) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 15-internal+0-2020-05-12-1648117.sspitsyn..., mixed mode, tiered, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x96276c] ConstantPoolCacheEntry::get_interesting_method_entry()+0x3c . . . . . . . Stack: [0x000014565cc4b000,0x000014565cd4b000], sp=0x000014565cd495c0, free space=1017k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x96276c] ConstantPoolCacheEntry::get_interesting_method_entry()+0x3c V [libjvm.so+0x965bb6] ConstantPoolCache::adjust_method_entries(bool*)+0xc6 V [libjvm.so+0x1084ad2] VM_RedefineClasses::AdjustAndCleanMetadata::do_klass(Klass*)+0x302 V [libjvm.so+0x88e36d] ClassLoaderData::classes_do(KlassClosure*)+0x3d V [libjvm.so+0x8988d9] ClassLoaderDataGraph::classes_do(KlassClosure*)+0x1b9 V [libjvm.so+0x1094b39] VM_RedefineClasses::doit()+0xd9 V [libjvm.so+0x1772a3c] VM_Operation::evaluate()+0x13c V [libjvm.so+0x17a0a95] VMThread::evaluate_operation(VM_Operation*) [clone .constprop.0]+0x125 V [libjvm.so+0x17a15ba] VMThread::loop()+0x89a V [libjvm.so+0x17a1938] VMThread::run()+0xc8 V [libjvm.so+0x16accf0] Thread::call_run()+0x100 V [libjvm.so+0x13b1726] thread_native_entry(Thread*)+0x116
13-05-2020
I don't understand how enabling another module could possibly fix a crash! Unless this test is hacking at VM internals these crashes indicate real problems in the VM! Further from the description this crash occurred when the Instrumentation was enabled, and as soon as we enable it permanently this crash has reappeared.
12-05-2020
Dan, thank you for re-opening the bug!
12-05-2020
I'm closing this one as "Cannot Reproduce". Leonid confirmed the Kitchensink does not fail with this anymore with the "Instrument" module enabled.
11-05-2020
I re-run current verion of KS with JDK11 GA and wasn't able to reproduce this failure.
15-04-2019
Kitchensink failed: https://java.se.oracle.com:10065/mdash/jobs/lmesnik-ks-apps-20190404-2152-1704810/tasks/lmesnik-ks-apps-20190404-2152-1704810-closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink_java-windows-x64-debug-35/results?search=status%3Afailed%20AND%20-state%3Ainvalid To run locally use: jib make -- run-test JTREG_RETAIN=all TEST=closed/test/hotspot/jtreg/applications/kitchensink/Kitchensink.java JTREG="VM_OPTIONS=-Dkitchensink.modules.additional=Instrumentation" to run in Mach5 use jib mach5 -- -t closed/test/hotspot/jtreg/applications/kitchensink/Kitchensink.java -a "-Dkitchensink.modules.additional=Instrumentation"
04-04-2019