JDK-5083062 : JVM crash in "instanceof" codelet, array of secondary supertypes at end of heap.
  • Type: Bug
  • Status: Closed
  • Resolution: Fixed
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P3
  • Affected Version: 6
  • OS: solaris_8
  • CPU: sparc
  • Submit Date: 2004-08-05
  • Updated Date: 2012-10-08
  • Resolved Date: 2004-08-30
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 Availabitlity Release.

To download the current JDK release, click here.
Other JDK 6
1.4.2_10Fixed 6 mustangFixed
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
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

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

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