United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6548306 j2sdk1.4.2_13 /server crash in ~StubRoutines::partial_subtype_check
JDK-6548306 : j2sdk1.4.2_13 /server crash in ~StubRoutines::partial_subtype_check

Details
Type:
Bug
Submit Date:
2007-04-20
Status:
Closed
Updated Date:
2014-05-16
Project Name:
JDK
Resolved Date:
2009-06-15
Component:
hotspot
OS:
solaris_8
Sub-Component:
runtime
CPU:
sparc
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.2_13,5.0
Fixed Versions:
1.4.2_21-rev (b05)

Related Reports
Backport:
Backport:
Backport:
Relates:

Sub Tasks

Description
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
            0x69000000 
+)          0xeb988000
Seems like we went past this limit.

                                    

Comments
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.
                                     
2007-05-18



Hardware and Software, Engineered to Work Together