JDK-8229179 : FindInstanceClosure::do_object crash during safepoint
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 13,14
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2019-08-06
  • Updated: 2019-11-18
  • Resolved: 2019-09-04
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 14
14Resolved
Related Reports
Duplicate :  
Description
V  [libjvm.so+0x7e5fc8]  FindInstanceClosure::do_object(oopDesc*)+0x58
V  [libjvm.so+0xe28f97]  void ZHeapIterator::objects_do<true>(ObjectClosure*)+0x177
V  [libjvm.so+0xe257de]  ZHeap::object_iterate(ObjectClosure*, bool)+0x2e
V  [libjvm.so+0x7e4d1b]  HeapInspection::find_instances_at_safepoint(Klass*, GrowableArray<oopDesc*>*)+0x4b
V  [libjvm.so+0xd7bf75]  ConcurrentLocksDump::dump_at_safepoint()+0xa5
V  [libjvm.so+0xdda5e0]  VM_ThreadDump::doit()+0x240
V  [libjvm.so+0xdda6f7]  VM_Operation::evaluate()+0xe7
V  [libjvm.so+0xde1577]  VMThread::evaluate_operation(VM_Operation*) [clone .constprop.68]+0xc7
V  [libjvm.so+0xde1cfe]  VMThread::loop()+0x67e
V  [libjvm.so+0xde1fd7]  VMThread::run()+0x77
V  [libjvm.so+0xd6f5dd]  Thread::call_run()+0x10d
V  [libjvm.so+0xbc21c7]  thread_native_entry(Thread*)+0xe7

Instruction seems to be:
cmp rsi,QWORD PTR [rdi+rdx*1]
jne loc_00000000

RSI=0x00007f859a903510 is a pointer to class: 
java.util.concurrent.locks.AbstractOwnableSynchronizer {0x00007f859a903510}
RDX=0x0000000000000038 is an unknown value
RDI=0x0000000000000001 is an unknown value

Comments
Will be fixed by JDK-8230565
04-09-2019

[~eosterlund] - I'm going to split the parallel GC sightings (with my bits) off into a new bug and only leave the ZGC sightings here. I have a couple of things to do first. I'm also in the process of getting the latest round of Async Monitor Deflation changes ready for OpenJDK review, but they are not ready yet. [~tschatzl], [~rehn], [~stefank], [~eosterlund] - I have split off the parallel-gc sighting with my Adhoc 8153224 bits into JDK-8230249. If you folks remove your comments above, the I'll remove this one and we'll have cleaned up this bug to be ZGC only.
27-08-2019

Added gc-parallel label to this CR as this is the collector for the crash [~dcubed] reported. However I would be surprised if that were a ZGC and Parallel only problem.
19-08-2019

[~stefank] Thanks. [~dcubed] No, I didn't have yours :) [~stefank] It seem like [~dcubed] was not ZGC. Did you only manage to reprod with ZGC? (I saw ZGC label)
08-08-2019

Managed to reproduce this on JDK 13 after ~19h by running Kitchensink and continuously invoke the code path above with: while true; do bin/jcmd <pid of stress process> Thread.print -l=true; done
07-08-2019

I also had some local changes, putting this as P5 until I'm certain those had nothing todo with it.
06-08-2019