JDK-6859817 : Regression: C2 compiler crash since 6u10
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.0
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2009-07-13
  • Updated: 2010-07-29
  • Resolved: 2009-07-28
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
6u18Resolved
Related Reports
Duplicate :  
JDK-6840775 - Multiple JVM crashes seen with 1.6.0_10 through early access of 1.6.0_14 - possibly related to GC
Relates :  
JDK-6793611 - CMS: crash in ParNewGeneration::copy_to_survivor_space_avoiding_promotion_undo
Description
Since 6u10 a crash in always the same compiled method is being observed.
The crash does not happen with 6u7 and earlier.
Comments
EVALUATION This bug is an instance of the Arrays.copyOf intrinsic bug, 6840775. I tracked the bad oop bad up the call stack and it came from a call to ArrayList.toArray which uses Arrays.copyOf. The final path is missing the register i0 from the oopmap so a stale oop value gets passed out if a gc occurs on that call. 0xffffffff7646129c: call 0xffffffff7606a380 0xffffffff764612a0: nop public java.lang.Object[] toArray(java.lang.Object[]) [signature <T:Ljava.lang.Object;>([TT;)[TT;] @0xffffff\ ff4add63c8 of public class java.util.ArrayList [signature <E:Ljava/lang/Object;>Ljava/util/AbstractList<TE;>;\ Ljava/util/List<TE;>;Ljava/util/RandomAccess;Ljava/lang/Cloneable;Ljava/io/Serializable;] @0xffffffff4add72c0\ @ bci = 21, line = 305 locals ([0], illegal) ([1], illegal) expressions ([0], L6, oop) ([1], I5, int) ([2], L2, oop) OopMap: Oop: L2 L6 0xffffffff764612a4: ba,pt %icc, 0xffffffff764611f0 0xffffffff764612a8: nop 0xffffffff764611f0: sethi %hi(0x847ffc00), %l0 0xffffffff764611f4: btog 0xfffffc00, %l0 0xffffffff764611f8: ldx [%l0 + 0x0], %g0 0xffffffff764611fc: ret 0xffffffff76461200: restore Once this is confirmed either with a patched build or a workaround we can close this as a duplicate.
17-07-2009
EVALUATION The crash is occurring in the generated code for MacroAssembler::compiler_lock_object. We appear to be on the casn below: // Try to CAS m->owner from null to Self // Invariant: if we acquire the lock then _recursions should be 0. add (Rmark, ObjectMonitor::owner_offset_in_bytes()-2, Rmark) ; mov (G2_thread, Rscratch) ; casn (Rmark, G0, Rscratch) ; cmp (Rscratch, G0) ; (dbx) dis $pc-2,$pc+1 0xffffffff76364f4c: inc 22, %l0 0xffffffff76364f50: mov %g2, %o7 0xffffffff76364f54: casx [%l0] , %g0, %o7 0xffffffff76364f58: cmp %o7, %g0 (dbx) p -flx $l0-22 $l0-22 = 0xfffffffe980412eb (dbx) p -flx $l0-22 & 7 $l0-22 & 7 = 0x3 The problem is that the value of Rmark contains an unexpected value in the low bits, 0x3, which is the value markOopDesc::marked_value. This isn't a valid value outside of a GC. It likely should be unlocked_value but somehow marked_value leaked out of the GC. It's possible this is an existing CMS and I'm trying confirm that this is possible.
15-07-2009