JDK-6548306 : j2sdk1.4.2_13 /server crash in ~StubRoutines::partial_subtype_check
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.2_13,5.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2007-04-20
  • Updated: 2014-05-16
  • Resolved: 2009-06-15
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.
1.4.2_21-rev b05Fixed
Related Reports
Relates :  
Customer is seeing crashes in compiled code.  They are running with 1.4.2_13 -server on Solaris 8 with T2 libthread.

In hs_err_pid3035.log attached, it shows 
# Problematic frame:
# v  ~StubRoutines::partial_subtype_check

(dbx) where -l 10
current thread: t@329
  [1] libc.so.1:__lwp_kill(0x0, 0x149, 0x0, 0xff33c008, 0xff386000, 0x0), at 0xff31f6d4
  [2] libc.so.1:raise(0x6, 0x0, 0x0, 0xffffffff, 0xff3403c4, 0x0), at 0xff2cbdbc
  [3] libc.so.1:abort(0xff33c008, 0x1, 0x1, 0xff180969, 0x1, 0x414c18), at 0xff2b5a54
  [4] libjvm.so:os::abort(0x1, 0xff180969, 0x1, 0x7efefeff, 0x81010100, 0xff00), at 0xff0ba674
  [5] libjvm.so:VMError::report_and_die(0xff196cbc, 0xff196ccb, 0xff196cdb, 0xfa000958, 0x4bdfdb80, 0x4bdfd8c8), at 0xff11f9e8
  [6] libjvm.so:JVM_handle_solaris_signal(0xfa000958, 0xfa000958, 0xff18046d, 0xeb988000, 0x4be00000, 0x4be00000), at 0xfeddb118
  [7] libthread.so.1:__sighndlr(0xb, 0x4bdfdb80, 0x4bdfd8c8, 0xfedda6cc, 0x0, 0x0), at 0xff374f94
  ---- called from signal handler with signal 11 (SIGSEGV) ------
=>[8] 0xfa000958(0x6bf9ada8, 0x6a8740a0, 0x6bf72450, 0x89928848, 0x0, 0x0), at 0xfa000958
  [9] 0xfa3e2b24(0x6bf9ae30, 0x0, 0x6a8740a0, 0x0, 0x0, 0xe90472d8), at 0xfa3e2b24
  [10] 0xfa40e14c(0x6bf9af30, 0x6bf72450, 0x89928848, 0x0, 0x0, 0x890ab590), at 0xfa40e14c
(dbx) dis 0xfa000900, 0xfa000958
0xfa000900:     inc      -16, %sp
0xfa000904:     st       %l0, [%sp + 64]
0xfa000908:     st       %l1, [%sp + 68]
0xfa00090c:     st       %l2, [%sp + 72]
0xfa000910:     st       %l3, [%sp + 76]
0xfa000914:     ld       [%o1 + 20], %l3
0xfa000918:     ld       [%l3 + 8], %l0
0xfa00091c:     add      %l3, 12, %l1
0xfa000920:     clr      %l3
0xfa000924:     ld       [%l1], %l2
0xfa000928:     nop
0xfa00092c:     nop
0xfa000930:     nop
0xfa000934:     nop
0xfa000938:     nop
0xfa00093c:     nop
0xfa000940:     inc      4, %l1
0xfa000944:     cmp      %l3, %l0
0xfa000948:     be,pn    %icc,0xfa000978        ! 0xfa000978
0xfa00094c:     inc      %l3
0xfa000950:     subcc    %l2, %o2, %o0
0xfa000954:     bne,pt   %icc,0xfa000940        ! 0xfa000940
0xfa000958:     ld       [%l1], %l2
(dbx) x $l1
0xeb988000:     dbx: core file read error: address 0xeb988000 not in data space

Looking at the pmap output, 
68FC0000    192K read
69000000 2139680K read/write/exec
F9020000    352K read

2139680K == 0x82988000
+)          0xeb988000
Seems like we went past this limit.

EVALUATION The direct cause of this issue is in stubGenerator.cpp: 1235 // Load a little early; will load 1 off the end of the array. 1236 // Ok for now; revisit if we have other uses of this routine. ... 1248 __ delayed()->ld_ptr(L1_ary_ptr,0,L2_super); // Will load a little early (The delayed ld above is executing +1 off the array which butts up against the end of the segment, and we have a hit on the last entry :( ) Its unclear that any thing other than bad luck gets us this alignment. Generated a version without the preload, and cu will test.