JDK-8019247 : SIGSEGV in compiled method c8e.e.t_.getArray(Ljava/lang/Class;)[Ljava/lang/Object;
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2013-06-27
  • Updated: 2014-01-15
  • Resolved: 2013-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 8 Other
8Fixed hs25Fixed
Related Reports
Relates :  
JDK-6934604 - enable parts of EliminateAutoBox by default
Description
During promotion testing of JDK 8 b94 with HS25 b36 crash has been observed:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xfffffd7ff8fac502, pid=13604, tid=42
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b94) (build 1.8.0-ea-b94)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b36 mixed mode solaris-amd64 compressed oops)
# Problematic frame:
# J  c8e.e.t_.getArray(Ljava/lang/Class;)[Ljava/lang/Object;
#

Crash happened on Server VMs with options used: -server -Xmixed -XX:+UseParallelGC

Test failed: punit/applications/cloudscape/CloudscapeFull/testFull
Comments
noreg-sqe: Change can be verified by running an existing SQE test suite
18-10-2013
Raising priority to P1 as the JCK's mirror issue - JDK-8019193 - as this is a showstopper for JCK8 progress - both in bugfixing and integrating new tests on the recent APIs which arrived in 8b94 and further.
02-07-2013
Undo change done in 6934604, it does not work for reflection allocation (java.lang.reflect.Array::newInstance()) : src/share/vm/opto/graphKit.cpp Fri Jun 28 20:21:36 2013 -0700 @@ -3332,8 +3332,10 @@ if (ptr == NULL) { // reduce dumb test in callers return NULL; } - ptr = ptr->uncast(); // strip a raw-to-oop cast - if (ptr == NULL) return NULL; + if (ptr->is_CheckCastPP()) { // strip a raw-to-oop cast + ptr = ptr->in(1); + if (ptr == NULL) return NULL; + } if (ptr->is_Proj()) { Node* allo = ptr->in(0);
29-06-2013
Correction: the offset is ObjArrayKlass::element_klass_offset(). And questionable code is generated in Parse::array_store_check().
29-06-2013
Good new is: only hs25/jdk8 is affected.
29-06-2013
mea culpa: 6934604
29-06-2013
We loading klass from newly allocated by reflection array and cast its type to general j.lO[] array. Then we do load ArrayKlass::component_mirror_offset() from that klass: 1cc + LDUW [R_I0 + #4],R_L0 ! klass ptr 1d0 + LDUW [R_L0 + #160],R_O2 ! klass ptr In failed case instead of loading klass from allocated array (offset +4 in 32-bit VM) we do next and I don't know WHY! 1cc + SET precise klass java/lang/Object: 0x000ff4a8:Constant:exact *,R_L0 !ptr 1d4 + LDUW [R_L0 + #160],R_O2 ! klass ptr j.l.O klass is instance klass and +160 offset corresponds to InstanceKlass::_generic_signature field and it is usually NULL so we die on next load: 1d8 + LDUW [R_O2 + #12],R_L1 ! int The failure started in jdk8 b91. I am now trying to narrow changeset.
29-06-2013
Note, that pointer to j.l.O.class is embedded into code as constant: movl 0xb9e00920(%ecx),%eax Someone asking to load from j.l.O.class+0x90.
28-06-2013
;; fffffd7ff8fac4fb 49 8b 85 f0 00 00 00 mov 0xf0(%r13),%rax ;; --------------- ;; fffffd7ff8fac502 8b 50 0c mov 0xc(%rax),%edx RAX=0x0000000000000000 R13=0x0000000039e00f40 The code could be loading from class metaspace (why we still don't have metaspace addresses in hs_err !!!). R13 points to the address below java heap: 0000000039E00000 2048K rw--- [ anon ] 000000003A000000 2048K rw--- [ anon ] 0000000040200000 77824K rw--- [ anon ] Heap: PSYoungGen total 730624K, used 702927K [0x00000000c0000000, 0x00000000fca00000, 0x0000000100000000) eden space 716288K, 96% used [0x00000000c0000000,0x00000000ea229e70,0x00000000ebb80000) from space 14336K, 87% used [0x00000000fbc00000,0x00000000fc84a030,0x00000000fca00000) to space 18944K, 0% used [0x00000000fa500000,0x00000000fa500000,0x00000000fb780000) ParOldGen total 77824K, used 18814K [0x0000000040200000, 0x0000000044e00000, 0x00000000c0000000) object space 77824K, 24% used [0x0000000040200000,0x000000004145fb28,0x0000000044e00000) Metaspace total 20740K, used 17383K, reserved 122880K data space 17856K, used 15032K, reserved 20480K class space 2884K, used 2351K, reserved 102400K It looks like the code loading from offset 0xf0 offset from klass and expects array there. Also hs_err dumper should correctly print class information for klass pointers in registers: RSI=0x0000000039fa43c0 is an unknown value RDI=0x00000000e9aa6bf0 is an oop [error occurred during error reporting (printing register info), id 0xb] Note, this is case with 32-bit pointers because java heap is below 4Gb address.
27-06-2013
Pavel, how to run this test?
27-06-2013
Wait, I am still looking this.
27-06-2013