JDK-8274787 : Kitchensink24HStress.java failed with EXCEPTION_ACCESS_VIOLATION in oopDesc::size_given_klass
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 18
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows
  • CPU: x86_64
  • Submitted: 2021-10-05
  • Updated: 2021-10-07
  • Resolved: 2021-10-07
Related Reports
Duplicate :  
JDK-8274340 - [BACKOUT] JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references
Relates :  
JDK-8235305 - Corrupted oops embedded in nmethods due to parallel modification during optional evacuation
Description
The following test failed in the JDK18 CI:

applications/kitchensink/Kitchensink24HStress.java

Here's snippets from the hs_err_pid file:

#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007fff9159b441, pid=35376, tid=13884
#
# JRE version: Java(TM) SE Runtime Environment (18.0+17) (build 18-ea+17-974)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (18-ea+17-974, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# V  [jvm.dll+0x1ab441]  oopDesc::size_given_klass+0x71
#
# Core dump will be written. Default location: T:\testoutput\test-support\jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink24HStress_java\scratch\0\hs_err_pid35376.mdmp
#
# JFR recording file will be written. Location: T:\testoutput\test-support\jtreg_closed_test_hotspot_jtreg_applications_kitchensink_Kitchensink24HStress_java\scratch\0\hs_err_pid35376.jfr

<snip>

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

Current thread (0x000001bf6feddd90):  GCTaskThread "GC Thread#5" [stack: 0x0000006de8900000,0x0000006de8a00000] [id=13884]

Stack: [0x0000006de8900000,0x0000006de8a00000],  sp=0x0000006de89ff268,  free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x1ab441]  oopDesc::size_given_klass+0x71  (oop.inline.hpp:204)


siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x0000000000000100

The only similar bug I found to this failure mode is:

JDK-8235305 Corrupted oops embedded in nmethods due to parallel modification during optional evacuation

so I'm starting this bug in hotspot/gc for initial triage.
Comments
Sorry for not being more detailed in this: looking at the hs_err log we see that we crash on the following reference: {0x00000007fd8949a0} - klass: 'java/lang/invoke/MethodType$ConcurrentWeakInternSet$WeakEntry' - ---- fields (total size 4 words): - private 'referent' 'Ljava/lang/Object;' @12 NULL (0) - volatile 'queue' 'Ljava/lang/ref/ReferenceQueue;' @16 a 'java/lang/ref/ReferenceQueue'{0x00000002080630b8} (4100c617) - volatile 'next' 'Ljava/lang/ref/Reference;' @20 NULL (0) - private transient 'discovered' 'Ljava/lang/ref/Reference;' @24 [error occurred during error reporting (printing register info), id 0xc0000005, EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007fff91a4f1e6] The "discovered" field is broken. A comment in JDK-8274340 (https://bugs.openjdk.java.net/browse/JDK-8274340?focusedCommentId=14449781&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14449781) shows a (verification) failure in exactly the same field for exactly the same type of klass (java/lang/invoke/MethodType$ConcurrentWeakInternSet$WeakEntry). The bug in JDK-8271880 has exactly been that we miss barriers on the discovered fields of java.lang.ref.Reference instances, as a comment in JDK-8274516 indicates. I believe this is enough proof that this is the same issue and we can close this as duplicate of JDK-8274340. Unfortunately, since gc tends to visit all reference fields over time, and there are multiple occasions we do that, a particular stack trace may not be indicative of a particular crash mode.
07-10-2021
[~tschatzl] - Thanks for the analysis.
07-10-2021
Only bugs associated with a changeset should be closed as "Fixed". Perhaps this bug should be closed as a duplicate of: JDK-8235305 Corrupted oops embedded in nmethods due to parallel modification during optional evacuation But it would be nice to have a little more analysis than what appears to be a guess that this is a duplicate. I don't disagree with your point that Kitchensink was crashing a lot before JDK-8235305 was fixed, but I didn't find another crash during that time frame that matched this one.
06-10-2021
Particularly kitchensink crashes quite a lot without that fix.
06-10-2021
[~tschatzl] - The artifacts are thin for this sighting, but this failure mode reminds me of: JDK-8235305 Corrupted oops embedded in nmethods due to parallel modification during optional evacuation so I figure you might be interested in this bug...
05-10-2021