JDK-8275277 : assert(dest_attr.is_in_cset() == (obj->forwardee() == obj)) failed: Only evac-failed objects must be in the collection set here but is not
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 18
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2021-10-14
  • Updated: 2022-02-10
  • Resolved: 2021-10-16
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 b20Fixed
Related Reports
Relates :  
JDK-8274516 - [REDO] JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references
Relates :  
JDK-8274452 - G1: Only evac-failed objects must be in the collection set here
Description
vmTestbase/gc/ArrayJuggle/Juggle29/TestDescription.java fails with

#  assert(dest_attr.is_in_cset() == (obj->forwardee() == obj)) failed: Only evac-failed objects must be in the collection set here but 0x000000074c600000 is not

Stack: [0x000070000874b000,0x000070000884b000],  sp=0x000070000884a860,  free space=1022k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x10f4799]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x6e9
V  [libjvm.dylib+0x10f4e1b]  VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x3b
V  [libjvm.dylib+0x5d615d]  report_vm_error(char const*, int, char const*, char const*, ...)+0xdd
V  [libjvm.dylib+0x76120b]  void G1ParScanThreadState::write_ref_field_post<narrowOop>(narrowOop*, oop)+0x18b
V  [libjvm.dylib+0x75c3b1]  void G1ParScanThreadState::do_oop_evac<narrowOop>(narrowOop*)+0x2b1
V  [libjvm.dylib+0x75ca4b]  G1ParScanThreadState::steal_and_trim_queue(GenericTaskQueueSet<OverflowTaskQueue<ScannerTask, (MEMFLAGS)5, 131072u>, (MEMFLAGS)5>*)+0x9b
V  [libjvm.dylib+0x79fd2c]  G1ParEvacuateFollowersClosure::do_void()+0x12c
V  [libjvm.dylib+0x79fad8]  G1EvacuateRegionsBaseTask::evacuate_live_objects(G1ParScanThreadState*, unsigned int, G1GCPhaseTimes::GCParPhases, G1GCPhaseTimes::GCParPhases)+0x98
V  [libjvm.dylib+0x79f832]  G1EvacuateRegionsBaseTask::work(unsigned int)+0xa2
V  [libjvm.dylib+0x11503be]  GangWorker::run_task(WorkData)+0x5e
V  [libjvm.dylib+0x11502a1]  GangWorker::loop()+0x41
V  [libjvm.dylib+0x1150166]  GangWorker::run()+0x16
V  [libjvm.dylib+0x1049457]  Thread::call_run()+0x177
V  [libjvm.dylib+0xe181f0]  thread_native_entry(Thread*)+0x150
Comments
Changeset: bfcf6a29 Author: Thomas Schatzl <tschatzl@openjdk.org> Date: 2021-10-16 11:05:48 +0000 URL: https://git.openjdk.java.net/jdk/commit/bfcf6a29a16bc12d77a897fbec304868957c3188
16-10-2021
Reproduction rate is ~0.15% (3 out of 2000) with ArrayJuggle28/29.
15-10-2021
Looking at some internally reproduced crash: p = 0x8441430c obj = {_o = 0x9e3c9800} region(p) = 421 | 421|0x000000009e300000, 0x000000009e400000, 0x000000009e400000|100%| O| |TAMS 0x000000009e300000, 0x000000009e300000| Untracked (not in cset, verified) $ x/20x obj._o 0x9e3c9800: 0x9e3c9801 0x00000000 0x00001e90 0x00000005 0x9e3c9810: 0x32ce8d46 0x3fe15beb 0xc979d300 0x3f6bb0bf 0x9e3c9820: 0x129e0829 0x3fe98775 0xa511e698 0x3fd02670 0x9e3c9830: 0x00000000 0x00000000 0x00000000 0x00000000 0x9e3c9840: 0x00000000 0x00000000 0x00000000 0x00000000 i.e. the object is locked (0x9e3c980*1*) assert(dest_attr.is_in_cset() == (obj->forwardee() == obj), false == (0x9e3c9801 & ~3 == 0x9e3c9800) false == true -> assertion failure The problem is that we assume that whatever forwardee() returns is actually a valid forwarding pointer.
15-10-2021
Here's the stack trace for the jdk-18+20-1183-tier5 sighting: --------------- T H R E A D --------------- Current thread (0x000001ff3d23d870): GCTaskThread "GC Thread#5" [stack: 0x0000006b6f700000,0x0000006b6f800000] [id=69596] Stack: [0x0000006b6f700000,0x0000006b6f800000] Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0xadab01] os::platform_print_native_stack+0xf1 (os_windows_x86.cpp:235) V [jvm.dll+0xcf7f1e] VMError::report+0x101e (vmError.cpp:828) V [jvm.dll+0xcf991e] VMError::report_and_die+0x7fe (vmError.cpp:1656) V [jvm.dll+0xcfa0a4] VMError::report_and_die+0x64 (vmError.cpp:1437) V [jvm.dll+0x4cda57] report_vm_error+0xb7 (debug.cpp:282) V [jvm.dll+0x5e90c4] G1ParScanThreadState::do_oop_evac<enum narrowOop>+0x3b4 (g1ParScanThreadState.cpp:214) V [jvm.dll+0x5ee65e] G1ParScanThreadState::trim_queue_to_threshold+0x1ae (g1ParScanThreadState.cpp:310) V [jvm.dll+0x5ee3b7] G1ParScanThreadState::steal_and_trim_queue+0x57 (g1ParScanThreadState.cpp:320) V [jvm.dll+0x60eb4a] G1ParEvacuateFollowersClosure::do_void+0x16a (g1YoungCollector.cpp:620) V [jvm.dll+0x60f497] G1EvacuateRegionsBaseTask::evacuate_live_objects+0x97 (g1YoungCollector.cpp:646) V [jvm.dll+0x60f5f5] G1EvacuateRegionsTask::evacuate_live_objects+0x25 (g1YoungCollector.cpp:713) V [jvm.dll+0x610661] G1EvacuateRegionsBaseTask::work+0x71 (g1YoungCollector.cpp:695) V [jvm.dll+0xd3dd5a] GangWorker::loop+0x8a (workgroup.cpp:239) V [jvm.dll+0xd3ddfd] GangWorker::run+0x1d (workgroup.cpp:206) V [jvm.dll+0xc78f74] Thread::call_run+0x1b4 (thread.cpp:365) V [jvm.dll+0xad94be] thread_native_entry+0xae (os_windows.cpp:544) C [ucrtbase.dll+0x1fb80] C [KERNEL32.DLL+0x84d4] C [ntdll.dll+0x51781]
14-10-2021
Here's the stack trace for the the jdk-18+20-1187-tier4 sighting: --------------- T H R E A D --------------- Current thread (0x00007fec475be5c0): WorkerThread "GC Thread#2" [stack: 0x0000700005452000,0x0000700005552000] [id=34307] Stack: [0x0000700005452000,0x0000700005552000], sp=0x00007000055518a0, free space=1022k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.dylib+0x10ee1d9] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x6e9 V [libjvm.dylib+0x10ee85b] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x3b V [libjvm.dylib+0x5d3f4d] report_vm_error(char const*, int, char const*, char const*, ...)+0xdd V [libjvm.dylib+0x75d55b] void G1ParScanThreadState::write_ref_field_post<narrowOop>(narrowOop*, oop)+0x18b V [libjvm.dylib+0x758701] void G1ParScanThreadState::do_oop_evac<narrowOop>(narrowOop*)+0x2b1 V [libjvm.dylib+0x758d9b] G1ParScanThreadState::steal_and_trim_queue(GenericTaskQueueSet<OverflowTaskQueue<ScannerTask, (MEMFLAGS)5, 131072u>, (MEMFLAGS)5>*)+0x9b V [libjvm.dylib+0x79b5cc] G1ParEvacuateFollowersClosure::do_void()+0x12c V [libjvm.dylib+0x79b378] G1EvacuateRegionsBaseTask::evacuate_live_objects(G1ParScanThreadState*, unsigned int, G1GCPhaseTimes::GCParPhases, G1GCPhaseTimes::GCParPhases)+0x98 V [libjvm.dylib+0x79b0d2] G1EvacuateRegionsBaseTask::work(unsigned int)+0xa2 V [libjvm.dylib+0x1149581] WorkerThread::run()+0x71 V [libjvm.dylib+0x1042f57] Thread::call_run()+0x177 V [libjvm.dylib+0xe12ca0] thread_native_entry(Thread*)+0x150 C [libsystem_pthread.dylib+0x68fc] _pthread_start+0xe0 C [libsystem_pthread.dylib+0x2443] thread_start+0xf
14-10-2021
I suspect that the assert is wrong due to memory visibility races since there have been no actual crashes so far.
14-10-2021