JDK-8225642 : ZGC: Crash due to bad oops being spilled to stack in load barriers
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 13
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-06-12
  • Updated: 2019-08-08
  • Resolved: 2019-07-02
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 13 JDK 14
13 b28Fixed 14Fixed
Related Reports
Duplicate :  
JDK-8226363 - assert(Universe::heap()->is_in_or_null(*loc)) failed: found non oop pointer
Duplicate :  
JDK-8224649 - ZGC crashes with assert(ZAddress::is_marked(addr)) failed: Should be marked
Relates :  
JDK-8227407 - ZGC: C2 loads and load barriers can get separated by safepoints
Relates :  
JDK-8225509 - clean_catch_blocks must add preds first
Description
Crash occurs with ZGC

[stress.process.out] #
[stress.process.out] # A fatal error has been detected by the Java Runtime Environment:
[stress.process.out] #
[stress.process.out] #  SIGSEGV (0xb) at pc=0x00007fc65eac0567, pid=11589, tid=11625
[stress.process.out] #
[stress.process.out] # JRE version: Java(TM) SE Runtime Environment (13.0) (fastdebug build 13-ea+0-1307)
[stress.process.out] # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 13-ea+0-1307, mixed mode, tiered, z gc, linux-amd64)
[stress.process.out] # Problematic frame:
[stress.process.out] # V  [libjvm.so+0x997567]  oopDesc::size_given_klass(Klass*)+0x17
[stress.process.out] #
Comments
The current theory is that this is related to the following scenario that we've seen in another Kitchensink run: 0x00007f9548fad46a: mov 0x18(%r8,%r11,8),%rdx ; screenBuf[y] read 0x00007f9548fad46f: test %rdx,0x20(%r15) ; load barrier test 0x00007f9548fad473: jne 0x7f9548fb0a0c ; jump to slow path if oop is bad 0x00007f9548fad479: mov %rdx,%r9 ; if slow path not taken 0x00007f9548fad47c: test %r9,%r9 ; slow path jumps to this location After the last instruction rdx isn't used anymore, but a later safepoint poll has rdx in the oop map. If the load barrier slow path is triggered, rdx contains a bad oop and we either assert with a failing Universe::heap()->is_in_or_null(...) check, or get a broken oop in later object graph iteration.
12-06-2019