JDK-6826736 : CMS: core dump with -XX:+UseCompressedOops
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6u14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux_suse_sles_10
  • CPU: x86
  • Submitted: 2009-04-06
  • Updated: 2010-05-08
  • Resolved: 2009-07-29
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 6 JDK 7 Other
6u16-revFixed 7Fixed hs14.2Fixed
Related Reports
Relates :  
JDK-6871919 - unexpected failure of compiler/6826736/Test.java on 32 bit JDK
Relates :  
JDK-6695810 - null oop passed to encode_heap_oop_not_null
Relates :  
JDK-6860407 - G1: crash during evacuation failure ostensibly due to prematurely collected reference
Relates :  
JDK-6851282 - JIT miscompilation results in null entry in array when using CompressedOops
Relates :  
JDK-6870879 - JVM crash while running SailFin system tests with -XX:+UseCompressedOops flag
Relates :  
JDK-6868950 - Crash in runtime of JDK 1.6.0 U14-P1 using 64 bit Compressed OOPs
Relates :  
JDK-6869196 - Fatal error in 6u14p with Compressed OOPs in monitor locking
Description
We get somewhat frequent process crashes with JDK 6_14 b04 running on x4100s -- by frequent, I mean that we are doing 24-hour stress tests, and we will get a failure maybe 20% of the time.

We never get an actual core file, though the hs_err file is attached (the error reported is always the same). I have been unable to reproduce this reliably, or with smaller heaps or less testing time. We have only observed this on our Linux machines (also are testing Solaris x86).
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/5314d85ffd54
27-07-2009
SUGGESTED FIX Fix deoptimization code and OopMapSet::all_do() to check for such oops values. During deoptimization convert them to NULL. Ignore them and NULL oops for GC.
23-07-2009
PUBLIC COMMENTS Problem: Compiled code may produce decoded oop = narrow_oop_base when a narrow oop implicit null check is used. The narrow_oop_base could be NULL or be the address of the page below heap depending on the used mode of compressed oops. Such decoded oop could live across a safepoint and as result referenced in oopMap and debug info. The implicit NULL exception code checks for such oop value but deoptimization code and GC does not. And this cause the problem. Solution: Fix deoptimization code and OopMapSet::all_do() to check for such oops values. During deoptimization convert them to NULL. Ignore them and NULL oops for GC.
23-07-2009
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5314d85ffd54
23-07-2009
EVALUATION The bug reproduces with not only CMS, but also UseParallelGC and (now, with compressed oops!) UseG1GC. It is now believed that this is a compiler2 optimization issue perhaps related to 6851282.
15-07-2009
EVALUATION The bug has resurfaced, albeit with lower frequency, in testing by submitter; hence reopening investigation.
08-06-2009
EVALUATION Not reproducible under test conditions (shared machine lab) or with latest 6u14 fcs candidate.
28-05-2009