JDK-7022055 : Intermittent VM crash on Solaris10 x64 Core 2 Duo system during compilation
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 6u24,8
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_10
  • CPU: x86
  • Submitted: 2011-02-24
  • Updated: 2013-10-10
  • Resolved: 2013-10-10
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.
Other
hs25Resolved
Related Reports
Relates :  
JDK-6772737 - JVM crashes in symbolOopDesc::as_klass_external_name() when -XX:+CMSIncrementalMode
Relates :  
JDK-6993141 - VMThread receives EXCEPTION_ACCESS_VIOLATION in DefNewGeneration::copy_to_survivor_space
Description
The following crash happened during Libraries 6 testing for jdk 6u24-rev-b00-2011-02-18:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xfe6fdf07, pid=18092, tid=2
#
# JRE version: 6.0_24
# Java VM: Java HotSpot(TM) Client VM (19.1-b04 mixed mode, sharing solaris-x86 )
# Problematic frame:
# V  [libjvm.so+0xfdf07]
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#


The hs and java files are attached.

Looks like the problem anywhere in the working with file system. See some extract from native and java stack below:

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xfdf07]
V  [libjvm.so+0xfdee2]
V  [libjvm.so+0x23785b]
v  ~RuntimeStub::throw_class_cast_exception Runtime1 stub
J  com.sun.tools.javac.zip.ZipFileIndexEntry.compareTo(Ljava/lang/Object;)I
j  java.util.Arrays.sort([Ljava/lang/Object;)V+17

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~RuntimeStub::throw_class_cast_exception Runtime1 stub
J  com.sun.tools.javac.zip.ZipFileIndexEntry.compareTo(Ljava/lang/Object;)I
J  java.util.Arrays.mergeSort([Ljava/lang/Object;[Ljava/lang/Object;III)V
J  java.util.Arrays.mergeSort([Ljava/lang/Object;[Ljava/lang/Object;III)V

The problem was reproducible 3 times. It was reproducible with jdk 1.6.0_24 rev b23 as well.
Not a regression.
See comments for more info.
Comments
Issue was caused by broken HW. See for details: INTJDK-7606750 There are issues wiht LAB HW. It caused a lot of bit flips.
10-10-2013
As per the agreement with SQE, memory corruption issues occurring on stt-34, stt-68, and stt-128 are being reassigned to SQE for further testing. After the memory has been replaced in the systems, PDIT has run Memtester86+ for at least 24 hrs, SQE should close the issues if they cannot be reproduced.
26-09-2013
I've run the memtester (http://pyropus.ca/software/memtester/) tool on stt-34.ru.oracle.com and got some interesting results. Memtester performs a lot of different test on a specified memory size over and over again. I ran over night and during the 11th round of tests the "Bit Flip"-test failed: Bit Flip : testing 227FAILURE: 0x10000000 != 0x00000000 at offset 0x01954740. Later on, during the 32nd round, a test called "Bit Spread" also failed: Bit Spread : testing 35FAILURE: 0x50000000 != 0x40000000 at offset 0x01954740. Both those failures are consistent with the problems we have seen on this machine. Also the fact that the memory stress test only triggered the failure twice during 12 hours, suggests that this is indeed very intermittent.
12-09-2013
So why does it always fiddle the upper bits of a klass pointer during GC? At least in this case?
16-05-2013
The crash reproduces with jdk8. I was able to reproduce it with a private build on the stt-34 machine.
13-05-2013
I think we should see if this crash reproduces in jdk8, if not close it as NR.
30-04-2013