JDK-8151256 : JVM crash in CompactibleSpace::adjust_pointers(), intermittently
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2016-03-04
  • Updated: 2016-06-20
  • Resolved: 2016-06-20
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 9
9Resolved
Related Reports
Relates :  
JDK-8152065 - TraceBytecodes breaks the interpreter expression stack
Relates :  
JDK-8152298 - "guarantee(seq->num() > 0) failed" in G1CollectorPolicy::predict_yg_surv_rate
Relates :  
JDK-8152695 - SEGV in g1_mark_as_young
Relates :  
JDK-8141420 - Compiler runtime entries don't hold Klass* from being GCed
Relates :  
JDK-8152552 - SEGV in G1PLABAllocator
Relates :  
JDK-8130261 - G1 SEGV in MarkSweep::mark_and_push()
Description
Observed JVM crash,  intermittently, in CompactibleSpace::adjust_pointers()+0xee:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f7b5aaa325e, pid=5097, tid=5205
#
# JRE version: Java(TM) SE Runtime Environment (9.0+107) (build 9-ea+107-2016-02-24-205307.javare.4520)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (9-ea+107-2016-02-24-205307.javare.4520, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xb7725e]  CompactibleSpace::adjust_pointers()+0xee
#
Comments
I was able to reproduce this eventually when running with the MainWrapper, rather than running directly, about once in 50K runs. With the fix for JDK-8152499 (G1ResManAllocator::_context_hwm is not incremented in thread safe manner) I've run for a week (about 600k runs, half with the wrapper) without hitting it or any of the other 3 types of failures I'd seen running this test.
31-03-2016
The TraceBytecodes code has a bug that it messes up the interpreter expression stack by pushing arguments. So apart from the fact that it reproduces with -XX:+TraceBytecodes, I don't see anything about this that is the same as 8130261. I'm trying to reproduce it, but I think it should go back to the GC team.
17-03-2016
This appears to be the same problem as 8130261, where an interpreter stack frame is corrupt and the next GC crashes as a result. It occurs with G1, Parallel, and CMS GC. When looking at 8130261, I added additional verification that catches the problem sooner. (The patch is linked to the bug report.) Adding that verification and running the failing program in this report shows the same problem: Either an expression stack entry or argument in an interpreter frame which is supposed to contain an oop instead contains a value which is not a heap pointer. The patch causes the value to be checked before it is pushed on the GC work list, rather than letting it get pushed and have GC fail somewhere down the line where we don't know where the value came from. I can get the failure to occur nearly every time on scaaa045 by running with TraceByteCodes enabled: $JAVA_HOME/bin/java -XX:+UnlockCommercialFeatures -XX:+ResourceManagement -XX:+TraceBytecodes HeapRetentionTest I'll re-assign this to the runtime subcomponent. See the comments near the end of 8130261 for more details.
07-03-2016