Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6548306

j2sdk1.4.2_13 /server crash in ~StubRoutines::partial_subtype_check

    Details

    • Subcomponent:
    • Resolved In Build:
      b05
    • CPU:
      sparc
    • OS:
      solaris_8
    • Verification:
      Verified

      Backports

        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.

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  kevinw Kevin Walls
                  Reporter:
                  fchoong Fui-Shien Choong (Inactive)
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  3 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:
                    Imported:
                    Indexed: