JDK-8273304 : SEGV in trim_queue_to_threshold
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 18
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2021-09-03
  • Updated: 2021-11-15
  • Resolved: 2021-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.
JDK 18
18 b16Resolved
Related Reports
Duplicate :  
JDK-8274053 - [BACKOUT] JDK-8270842: G1: Only young regions need to redirty outside references in remset.
Relates :  
JDK-8274516 - [REDO] JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references
Relates :  
JDK-8270842 - G1: Only young regions need to redirty outside references in remset.
Description
Test: jdk/internal/shellsupport/doc/JavadocHelperTest.java
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f7a24f01df1, pid=30772, tid=31016
#
# JRE version: OpenJDK Runtime Environment (18.0+14) (build 18-ea+14-704)
# Java VM: OpenJDK 64-Bit Server VM (18-ea+14-704, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x6d7df1]  G1ParScanThreadState::trim_queue_to_threshold(unsigned int)+0x19b1

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

Current thread (0x00007f79e8007890):  GCTaskThread "GC Thread#1" [stack: 0x00007f79ee462000,0x00007f79ee562000] [id=31016]

Stack: [0x00007f79ee462000,0x00007f79ee562000],  sp=0x00007f79ee560a70,  free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x6d7df1]  G1ParScanThreadState::trim_queue_to_threshold(unsigned int)+0x19b1
V  [libjvm.so+0x6f46ea]  G1ScanHRForRegionClosure::scan_heap_roots(HeapRegion*)+0x53a
V  [libjvm.so+0x6eaec7]  G1RemSet::scan_heap_roots(G1ParScanThreadState*, unsigned int, G1GCPhaseTimes::GCParPhases, G1GCPhaseTimes::GCParPhases, bool)+0x1a7
V  [libjvm.so+0x69282b]  G1EvacuateRegionsTask::scan_roots(G1ParScanThreadState*, unsigned int)+0x4b
V  [libjvm.so+0x692f03]  G1EvacuateRegionsBaseTask::work(unsigned int)+0x83
V  [libjvm.so+0xdecbff]  GangWorker::loop()+0x5f
V  [libjvm.so+0xdecc5f]
V  [libjvm.so+0xd413d0]  Thread::call_run()+0xc0
V  [libjvm.so+0xba7591]  thread_native_entry(Thread*)+0xe1

R12=0x00000000fdb7aa39 is pointing into object: java.lang.ref.ReferenceQueue 
{0x00000000fdb7aa20} - klass: 'java/lang/ref/ReferenceQueue'
 - ---- fields (total size 4 words):
 - private final 'lock' 'Ljava/lang/ref/ReferenceQueue$Lock;' @12  a 'java/lang/ref/ReferenceQueue$Lock'{0x00000000fdb7aa40} (fdb7aa40)
 - private 'queueLength' 'J' @16  7 (7 0)
 - private volatile 'head' 'Ljava/lang/ref/Reference;' @24  
[error occurred during error reporting (printing register info), id 0xb, SIGSEGV (0xb) at pc=0x00007f7a253badf4]
Comments
Verified that this no longer happens after final fix for JDK-8274516. Also verified that the issue went away with the backout of JDK-8270842. Closing this issue as a duplicate of JDK-8274053 (which is the backout of JDK-8270842).
15-11-2021
Not been able to reproduce this exactly as in this bug, but with this test and a build from the same source as the original failure I've been able to trigger a verification failure: --- [79,311s][error][gc,verify] GC(236) Missing rem set entry: [79,311s][error][gc,verify] GC(236) Field 0x00000000d8df1a18 of obj 0x00000000d8df1a00 in region 141:(O)[0x00000000d8d00000,0x00000000d8e00000,0x00000000d8e00000] [79,311s][error][gc,verify] GC(236) NULL card setjava.lang.ref.SoftReference [79,311s][error][gc,verify] GC(236) {0x00000000d8df1a00} - klass: 'java/lang/ref/SoftReference' [79,311s][error][gc,verify] GC(236) - ---- fields (total size 5 words): [79,311s][error][gc,verify] GC(236) - private 'referent' 'Ljava/lang/Object;' @12 NULL (0) [79,311s][error][gc,verify] GC(236) - volatile 'queue' 'Ljava/lang/ref/ReferenceQueue;' @16 a 'java/lang/ref/ReferenceQueue$Null'{0x00000000d090eef8} (d090eef8) [79,311s][error][gc,verify] GC(236) - volatile 'next' 'Ljava/lang/ref/Reference;' @20 NULL (0) [79,311s][error][gc,verify] GC(236) - private transient 'discovered' 'Ljava/lang/ref/Reference;' @24 a 'java/lang/ref/WeakReference'{0x00000000fe65cc70} (fe65cc70) [79,311s][error][gc,verify] GC(236) - private 'timestamp' 'J' @32 11715735312 (ba4fef10 2) [79,311s][error][gc,verify] GC(236) points to obj 0x00000000fe65cc70 in region 742:(S)[0x00000000fe600000,0x00000000fe700000,0x00000000fe700000] remset Complete [79,311s][error][gc,verify] GC(236) java.lang.ref.WeakReference [79,311s][error][gc,verify] GC(236) {0x00000000fe65cc70} - klass: 'java/lang/ref/WeakReference' [79,311s][error][gc,verify] GC(236) - ---- fields (total size 4 words): [79,311s][error][gc,verify] GC(236) - private 'referent' 'Ljava/lang/Object;' @12 NULL (0) [79,311s][error][gc,verify] GC(236) - volatile 'queue' 'Ljava/lang/ref/ReferenceQueue;' @16 a 'java/lang/ref/ReferenceQueue$Null'{0x00000000d090eef8} (d090eef8) [79,311s][error][gc,verify] GC(236) - volatile 'next' 'Ljava/lang/ref/Reference;' @20 NULL (0) [79,311s][error][gc,verify] GC(236) - private transient 'discovered' 'Ljava/lang/ref/Reference;' @24 a 'java/lang/ref/WeakReference'{0x00000000fe8d1a70} (fe8d1a70) [79,311s][error][gc,verify] GC(236) Obj head CTE = -1, field CTE = -1. --- The discovered field of the soft reference is missing a rem set entry and the cause for that is most likely the problems introduced with JDK-8270842 and finally fixed with JDK-8274516. The object not correctly "remembered" is a WeakReference and looking at the original issue this could be what happened there as well. The second error occurs when trying to write the head of a ReferenceQueue, which could point to the missed WeakReference (and thus explain the failure to write). Currently rerunning the test with verification on the sources including the final fix for JDK-8274516.
12-11-2021
There are some interesting similarities with other crashes with this method on the stack. JDK-8273108: Stack: [0x00007f2dda963000,0x00007f2ddaa63000], sp=0x00007f2ddaa61980, free space=1018k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x13d19b0] markWord::displaced_mark_helper() const+0x60 V [libjvm.so+0xcac6ec] G1ParScanThreadState::do_copy_to_survivor_space(G1HeapRegionAttr, oop, markWord)+0x2cc V [libjvm.so+0xcb18e0] void G1ParScanThreadState::do_oop_evac<narrowOop>(narrowOop*)+0xd0 V [libjvm.so+0xcad6f3] G1ParScanThreadState::trim_queue_to_threshold(unsigned int)+0x343 and note the R12 register info in the main description which indicates we are interacting with the Lock object of ReferenceQueue - which may also involve looking at the markword. It is telling that we hit a secondary error trying to fully examine that object.
03-09-2021