JDK-8293881 : nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption failed with EXCEPTION_ACCESS_VIOLATION with ZGC
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 20
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: windows
  • CPU: x86_64
  • Submitted: 2022-09-15
  • Updated: 2022-11-15
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.
Other
tbdUnresolved
Related Reports
Duplicate :  
JDK-8296101 - nmethod::is_unloading result unstable with concurrent unloading
Relates :  
JDK-8258825 - strange crashes with applications/jcstress on AMD EPYC
Relates :  
JDK-8293832 - Kitchensink24HStress.java failed with EXCEPTION_ACCESS_VIOLATION in a C-frame
Relates :  
JDK-8293648 - Kitchensink.java failed with SIGSEGV in compiled frame with ZGC
Description
The following test failed in the JDK20 CI:

vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java

Here's a snippet from the log file:

>>>>>>>> Invoke RedefineClasses():
	new class byte count=2354
[21.747s][trace][redefine,class,iklass,add  ] adding previous version ref for MyClass, EMCP_cnt=7
[21.747s][trace][redefine,class,iklass,purge] MyClass: previous versions
[21.747s][trace][redefine,class,iklass,purge] previous version 0x0000000801176c60 is alive
[21.747s][trace][redefine,class,iklass,purge] previous version 0x000000080117b000 is alive
[21.747s][trace][redefine,class,iklass,purge] previous version 0x0000000801176800 is alive
[21.747s][trace][redefine,class,iklass,purge] previous version stats: live=3, deleted=0
[21.747s][trace][redefine,class,iklass,add  ] scratch class added; one of its methods is on_stack.
<<<<<<<< RedefineClasses() is successfully done
>>>>>>>> Invoke RedefineClasses():
	new class byte count=2354
[21.999s][trace][redefine,class,iklass,purge] Class unloading: has_previous_versions = true
[22.000s][trace][redefine,class,iklass,purge] MyClass: previous versions
[22.000s][trace][redefine,class,iklass,purge] previous version 0x0000000801177000 is alive
[22.000s][trace][redefine,class,iklass,purge] previous version 0x0000000801176c60 is alive
[22.000s][trace][redefine,class,iklass,purge] previous version 0x000000080117b000 is dead.
[22.000s][trace][redefine,class,iklass,purge] previous version 0x0000000801176800 is dead.
[22.000s][trace][redefine,class,iklass,purge] previous version stats: live=2, deleted=2
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000000000000, pid=19516, tid=28940
#
# JRE version: Java(TM) SE Runtime Environment (20.0+15) (fastdebug build 20-ea+15-1009)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 20-ea+15-1009, mixed mode, sharing, tiered, compressed class ptrs, z gc, windows-amd64)
# Problematic frame:
# 
[error occurred during error reporting (printing problematic frame), id 0xe0000000, Internal Error (c:\\sb\\prod\\1663116827\\workspace\\open\\src\\hotspot\\cpu\\x86\\frame_x86.inline.hpp:62)]

# Core dump will be written. Default location: C:\\sb\\prod\\1663276484\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jvmti_quick\\scratch\\5\\hs_err_pid19516.mdmp
#
# An error report file with more information is saved as:
# C:\\sb\\prod\\1663276484\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jvmti_quick\\scratch\\5\\hs_err_pid19516.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
----------System.err:(0/0)----------
----------rerun:(42/6791)*----------

Here's the crashing thread's stack:

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

Current thread (0x0000020eb471f3d0):  VMThread "VM Thread" [stack: 0x000000fe45100000,0x000000fe45200000] [id=28940]

Stack: [0x000000fe45100000,0x000000fe45200000]
[error occurred during error reporting (printing stack bounds), id 0xe0000000, Internal Error (c:\sb\prod\1663116827\workspace\open\src\hotspot\cpu\x86\frame_x86.inline.hpp:62)]

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)


siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), data execution prevention violation at address 0x0000000000000000
Comments
This bug was previously closed as a duplicate of: JDK-8296101 nmethod::is_unloading result unstable with concurrent unloading which was fixed on 2022.11.03 (in jdk-20+23-1601). This failure happened in jdk-20+24-1730-tier6 so that's more than 100 build-IDs later...
15-11-2022
Here's a log file snippet from the jdk-20+24-1730-tier6 sighting: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java >>>>>>>> Invoke RedefineClasses(): new class byte count=2350 [223.560s][trace][redefine,class,iklass,purge] Class unloading: has_previous_versions = true [223.560s][trace][redefine,class,iklass,purge] MyClass: previous versions [223.560s][trace][redefine,class,iklass,purge] previous version 0x0000000801187800 is dead. [223.561s][trace][redefine,class,iklass,purge] previous version 0x000000080118e460 is dead. [223.561s][trace][redefine,class,iklass,purge] previous version 0x0000000801182230 is dead. [223.561s][trace][redefine,class,iklass,purge] previous version 0x0000000801187c60 is alive [223.561s][trace][redefine,class,iklass,purge] previous version 0x0000000801182460 is dead. [223.561s][trace][redefine,class,iklass,purge] previous version 0x0000000801153a30 is dead. [223.562s][trace][redefine,class,iklass,purge] previous version stats: live=1, deleted=5 # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00000166875535e5, pid=66308, tid=37640 # # JRE version: Java(TM) SE Runtime Environment (20.0+24) (fastdebug build 20-ea+24-1730) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 20-ea+24-1730, mixed mode, sharing, tiered, compressed class ptrs, z gc, windows-amd64) # Problematic frame: # [error occurred during error reporting (printing problematic frame), id 0xc0000005, EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ff9e800e814] # Core dump will be written. Default location: C:\\sb\\prod\\1668513279\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jvmti_quick\\scratch\\2\\hs_err_pid66308.mdmp # # An error report file with more information is saved as: # C:\\sb\\prod\\1668513279\\testoutput\\test-support\\jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jvmti_quick\\scratch\\2\\hs_err_pid66308.log [224.355s][warning][os ] Loading hsdis library failed # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # ----------System.err:(0/0)---------- ----------rerun:(42/6791)*---------- Here's the crashing thread's stack: --------------- T H R E A D --------------- Current thread (0x00000166f5241410): VMThread "VM Thread" [stack: 0x00000001d1700000,0x00000001d1800000] [id=37640] Stack: [0x00000001d1700000,0x00000001d1800000], sp=0x00000001d17ff1e8, free space=1020k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x00000166875535e5 siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x0000000000000448
15-11-2022
It looks like all these crashes were with ZGC after the sweeper was removed (JDK-8290025). If that's the case JDK-8296101 might explain all the crashes.
01-11-2022
One of the crashes is similar to JDK-8293832: reading from a non-canonical address reports the address as 0xffffffffffffffff.
26-10-2022
In the most recent crash, it looks like a call through a C++ vtable ended up in bad memory. Possibly related to JDK-8293648.
01-10-2022
Targeted to tbd and unassigned myself from this issue for now.
20-09-2022
[~dlong] - Thanks for the suggestion. I've linked to JDK-8258825.
15-09-2022