United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-5083062 : JVM crash in "instanceof" codelet, array of secondary supertypes at end of heap.

Details
Type:
Bug
Submit Date:
2004-08-05
Status:
Closed
Updated Date:
2012-10-08
Project Name:
JDK
Resolved Date:
2004-08-30
Component:
hotspot
OS:
solaris_8
Sub-Component:
runtime
CPU:
sparc
Priority:
P3
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:

Related Reports
Backport:
Backport:

Sub Tasks

Description
Running in interpreted mode, the "instanceof" codelet can crash if it has to traverse a list of superclasses which is right at the end of the java heap: it can make a brief but fatal reference to a memory address in an unmapped region.


Native stack with additional info from Serviceability Agent:

 [9] libthread.so.1:sigacthandler(0x3d047a00, 0x3437e470, 0x3437e1b8, 0xff388000, 0x3437e470, 0xb), at 0xff36fa7c
  ---- called from signal handler with signal 11 (SIGSEGV) ------
=>[10] 0xfa016d90(0x3437e5c4, 0xb8, 0x0, 0xfa0122e8, 0x0, 0x0), at 0xfa016d8f

 - protected static de.rbg.nbs.app.gkr.peer.model.GKRApplicationModel 
 checkRefs(de.rbg.nbs.app.gkr.peer.model.GKRApplicationModel) @0xccb89948 
 @bci = 1, line = 128, pc = 0xfa016d90 (Interpreted)
 
Which is:

 line bci
 128  1????instanceof #27 [Class de.rbg.nbs.app.gkr.peer.model.AMVorgangDetail]
 
  [11] 0xfa005750(0x3437e654, 0xb8, 0x0, 0xfa016250, 0x4, 0x3437e568), at 0xfa00574f
  [12] 0xfa005750(0x3437e6fc, 0xb8, 0x0, 0xfa016250, 0x4, 0x3437e5e0), at 0xfa00574f
  [13] 0xfa005750(0x3437e7ac, 0xb8, 0x0, 0xfa015ea0, 0xc, 0x3437e690), at 0xfa00574f
  [14] 0xfa005750(0x3437e844, 0xb8, 0x0, 0xfa016250, 0x8, 0x3437e748), at 0xfa00574f
  [15] 0xfa005750(0x3437e8f4, 0xb6, 0x0, 0xfa016250, 0x4, 0x3437e7d0), at 0xfa00574f
  [16] 0xfa005750(0x3437e99c, 0xb6, 0x0, 0xfa015e50, 0x8, 0x3437e880), at 0xfa00574f
  [17] 0xfa005750(0x3437ea34, 0x0, 0x0, 0xfa015e50, 0x4, 0x3437e930), at 0xfa00574f
  [18] 0xfa00010c(0x3437eac0, 0x3437ebf8, 0xa, 0xcf21cd10, 0x8, 0x3437e9d0), at 0xfa00010b
  [19] libjvm.so:JavaCalls::call_helper(0x3437ebf0, 0x3437ebec, 0x3437ec24, 0xf98000, 0xf98000, 0xfee16b7c), at 0xfed5bcf8
  [20] libjvm.so:Reflection::invoke(0x0, 0x3437ed50, 0xff1d5e30, 0x1, 0xcb5f2570, 0xc), at 0xfee16cc4
  [21] libjvm.so:Reflection::invoke_method(0x4b51f390, 0x3437edd8, 0x3437edd4, 0xf98000, 0xfeeaa204, 0x0), at 0xfeea2f54


The "instanceof" has got to the code generated by:

void InterpreterMacroAssembler::gen_subtype_check 

...to the section that traverses the list of "secondary supertypes"

We are traversing the list of these secondary supertypes, a list of 13 elements in this case.

We are about to exit the loop, but the delay slot for that exit jump loads the NEXT element in the array.  This is usually innocuous, but in this case causes a SEGV.

                                    

Comments
PUBLIC COMMENTS


Running in interpreted mode, the "instanceof" codelet can crash if it has to traverse a list of superclasses which is right at the end of the java heap: it can make a brief but fatal reference to a memory address in an unmapped region.
                                     
2004-09-08
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mustang

FIXED IN:
mustang

INTEGRATED IN:
mustang


                                     
2004-09-08
WORK AROUND

None.
                                     
2004-09-08
SUGGESTED FIX


hotspot/src/cpu/sparc/vm/interp_masm_sparc.cpp

597   // Top of search loop
598   bind( loop );
599   br( Assembler::equal, false, Assembler::pn, not_subtype );
600   // In delay slot, load next super to check
601   delayed()->ld_ptr( Rtmp2, arrayOopDesc::base_offset_in_bytes(T_OBJECT), Rtmp3 );  <--- SEGV here
602 

I don't think I'm going out on a limb to suggest a nop in the delay slot would avoid this specific crash:

   597    // Top of search loop
   598    bind( loop );
   599    br( Assembler::equal, false, Assembler::pn, not_subtype );
   600    // put NOP In delay slot, THEN load next super to check
   601    delayed()->nop();
   602    ld_ptr( Rtmp2, arrayOopDesc::base_offset_in_bytes(T_OBJECT), Rtmp3 );
   603  

                                     
2004-09-08
EVALUATION

The suggested fix is correct. In the case where there 
is an empty secondary super list, the code will reference beyond
the enf of the objArrayOop which could cause a crash if the
object were located at the end of the heap.

###@###.### 2004-08-09
                                     
2004-08-09



Hardware and Software, Engineered to Work Together