JDK-8257993 : vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 11,16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-12-09
  • Updated: 2023-07-25
  • Resolved: 2020-12-09
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 16
11.0.21-oracleFixed 16 b28Fixed
Related Reports
Duplicate :  
JDK-8286933 - nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crashes intermittently in resolving the latest version of redefined method
Relates :  
JDK-6962688 - JVM failed w/ 'guarantee((retry_count++ < 100),..."' while being profiled w/ NetBeans6.8
Description
vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java crash intermittently when run with -XX:-TieredCompilation

#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (./open/src/hotspot/share/interpreter/interpreterRuntime.cpp:879), pid=51380, tid=48196
# guarantee((retry_count++ < 100)) failed: Could not resolve to latest version of redefined method
#
# JRE version: Java(TM) SE Runtime Environment (14.0.2+4) (build 14.0.2+4-36)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (14.0.2+4-36, compiled mode, sharing, compressed oops, g1 gc, windows-amd64)
# Core dump will be written. Default location: T:\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jvmti\\scratch\\3\\hs_err_pid51380.mdmp
#
# An error report file with more information is saved as:
# T:\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jvmti\\scratch\\3\\hs_err_pid51380.log
#
# If you would like to submit a bug report, please visit:
# https://bugreport.java.com/bugreport/crash.jsp
#
Comments
Fix Request (11u) Should get back ported for parity with 11.0.21-oracle. Commit with full hash: https://github.com/openjdk/jdk/commit/0a3e446ad95b09de2facee7107f7c1206339ee0d Patch (from jdk16) did not apply at all. Basically, it is a fresh implementation, guided by the original fix. Had to introduce new method "Method* get_new_method() const;" in method.hpp. Did not exist in 11. Local testing successful. SAP internal nightly build and test did not show any issues. Reviewed.
21-07-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/2051 Date: 2023-07-20 14:28:35 +0000
20-07-2023
Changeset: 0a3e446a Author: Coleen Phillimore <coleenp@openjdk.org> Date: 2020-12-09 23:08:52 +0000 URL: https://git.openjdk.java.net/jdk/commit/0a3e446a
09-12-2020
In the core file, 'info' has been optimized away so you can't see what the method is. In lldb it's resolving an invokespecial bytecode: (lldb) p bytecode (Bytecodes::Code) $0 = _invokespecial Luckily there's the SA jstack command which shows that. 0x0000000111c29dc2 * jdk.internal.reflect.GeneratedConstructorAccessor1.newInstance(java.lang.Object[]) bci:24 (Interpreted frame) Then SA: hsdb> class jdk.internal.reflect.GeneratedConstructorAccessor1 jdk/internal/reflect/GeneratedConstructorAccessor1 @0x0000000800dbb400 hsdb> dumpclass jdk.internal.reflect.GeneratedConstructorAccessor1 and javap -c jdk/internal/reflect/GeneratedConstructorAccessor1 public java.lang.Object newInstance(java.lang.Object[]) throws java.lang.reflect.InvocationTargetException; ... 24: invokespecial #10 // Method MyClass."<init>":()V Which is the class that's being continuously redefined: Event: 234.337 Thread 0x00007fe270d410d0 redefined class name=MyClass, count=2220 Event: 234.395 Thread 0x00007fe270d410d0 redefined class name=MyClass, count=2221 So there's a safepoint in resolve_invoke() when checking class constraints, and this safepoint could stop and cause the class to be redefined 100 times in this loop. In lldb in the core file, the rest of the threads are waiting to redefine this class too.
09-12-2020
This code has been there forever. Strange that it's failing so much now. LinkResolver::resolve_invoke seems to have a cached version of the old method that hasn't been updated. if (JvmtiExport::can_hotswap_or_post_breakpoint()) { int retry_count = 0; while (info.resolved_method()->is_old()) { // It is very unlikely that method is redefined more than 100 times // in the middle of resolve. If it is looping here more than 100 times // means then there could be a bug here. guarantee((retry_count++ < 100), "Could not resolve to latest version of redefined method"); // method is redefined in the middle of resolve so re-try. LinkResolver::resolve_invoke(info, receiver, pool, last_frame.get_index_u2_cpcache(bytecode), bytecode, CHECK); } } I've left this code as is, but this should be an assert(!is_old()) and LinkResolver should substitute the new Method in CallInfo if the method becomes old. It shouldn't have to reresolve the method since resolution is the same.
09-12-2020