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

1.3_b07 volanotest with C1, debug, unexpected sig 11

    XMLWordPrintable

    Details

    • Subcomponent:
    • CPU:
      x86
    • OS:
      solaris_7

      Description

      On Intel: 450 MHz 2 CPU

      1,3 B07:

      Running volanotest with C1, mixed, debug with the following flags:
      TraceOopMapGeneration, StressDerivedPointers, GCALotAtAllSafepoints
      VerifyBeforeGC and TraceMarkSweep, UseSlowPath:

      Got: "unexpected signal 11"

      I have seen this twice in the past week.

      The first time, there was a reference on the stack to an object
      containing "baadbabe".

      The second time, here is the stack:

       [7] JVM_handle_solaris_signal(sig = 11, info = 0x8ae5f7c, ucVoid =
      0x8ae5dabort_if_unrecognized = 1), line 941 in "os_solaris_i486.cpp"
        [8] signalHandler(sig = 11, info = 0x8ae5f7c, ucVoid = 0x8ae5d7c),
      line 19n "os_solaris.cpp"
        [9] __sighndlr(0xb, 0x8ae5f7c, 0x8ae5d7c, 0x83da1c0), at 0xdff992b3
        [10] sigacthandler(), at 0xdffa60f7
        ---- called from signal handler with signal 11 (SIGSEGV) ------
        [11] 0x87a57a8(0x0), at 0x87a57a7
        [12] fgets(), at 0xdfecaa5c
        [13] 0x879a56d(), at 0x879a56c
        [14] 0x879a56d(), at 0x879a56c
        [15] 0x879a56d(), at 0x879a56c
        [16] 0x879a56d(), at 0x879a56c
        [17] 0x879a5c1(), at 0x879a5c0
        [18] 0x879a693(), at 0x879a692
        [19] 0x86d5abf(0xc5f02b6c, 0xc5f02d08, 0xa, 0xda416698, 0x879cf60,
      0xc5f02 0x1, 0x8ac7820), at 0x86d5abe
        [20] JavaCalls::call_helper(result = 0xc5f02d04, m = 0xc5f02c2c, ar
      gs = 0x2c90, __the_thread__ = 0x8ac7820), line 347 in "javaCalls.cpp"


      I don't know where the fgets reference comes from - I believe that
      code is frameless, and I can't find how dbx finds that in the
      stack traces when I walk through this manually.

      The address which has called itself 4 times: 0x879a56d:
      0x0879a543: movl -20(%ebp),%esi
      0x0879a546: movl -16(%ebp),%edi
      0x0879a549: xorl %ebx,%ebx
      0x0879a54b: movb 2(%esi),%bl
      0x0879a54e: addl $2,%esi
      0x0879a551: jmp *_active_table+0xc00(,%ebx,4)
      0x0879a558: movl -20(%ebp),%esi
      0x0879a55b: movl -16(%ebp),%edi
      0x0879a55e: xorl %ebx,%ebx
      0x0879a560: movb 2(%esi),%bl
      0x0879a563: addl $2,%esi
      0x0879a566: jmp *_active_table+0x1000(,%ebx,4) <-----
      0x0879a56d: movl -20(%ebp),%esi
      0x0879a570: movl -16(%ebp),%edi
      0x0879a573: xorl %ebx,%ebx
      0x0879a575: movb 3(%esi),%bl
      0x0879a578: addl $3,%esi
      0x0879a57b: jmp *_active_table(,%ebx,4)

      The fgets code we appear to come from:

      0xdfecaa54: fgets+0x00a0: jg fgets+0xe8 <0xdfecaa9c>
      0xdfecaa56: fgets+0x00a2: pushl %esi
      0xdfecaa57: fgets+0x00a3: call _PROCEDURE_LINKAGE_TABLE_+0x15
      30 [PLT] <0xdfe8f0d0>
      0xdfecaa5c: fgets+0x00a8: addl $4,%esp

      where PLT+0x1530/
      (/net/brandx/intel/tools/SUNWspro/SC5.0/WS5.0/bin/dbx.cmpx) dis 0xdfe
      8f0d0/10 >
      0xdfe8f0d0: _PROCEDURE_LINKAGE_TABLE_+0x1530 [PLT]: jmp *0x000
      0070c(%ebx)
      Code which caused the signal 11: (0x87a57a8)

      0x087a576a: addb (%eax),%al
      0x087a576c: addb %al,(%eax)
      0x087a576e: pushl %edx
      0x087a576f: pushl %eax
      0x087a5770: xorl %edx,%edx
      0x087a5772: movw 1(%esi),%dx
      0x087a5776: movl -12(%ebp),%ecx
      0x087a5776: movl -12(%ebp),%ecx
      0x087a5779: shll $2,%edx
      0x087a577c: movl 24(%ecx,%edx,4),%ebx
      0x087a5780: movl 28(%ecx,%edx,4),%edx
      0x087a5784: movl %esi,-20(%ebp)
      0x087a5787: movl %edx,%ecx
      0x087a5789: andl $0xff,%ecx
      0x087a578f: shrl $0x1d,%edx
      0x087a5792: movl -4(%esp,%ecx,4),%ecx
      0x087a5796: movl 0x86cf41c(,%edx,4),%edx
      0x087a579d: pushl %edx
      0x087a579e: movl 4(%ecx),%eax
      0x087a57a1: movl -88(%eax,%ebx,4),%ebx
      0x087a57a8: movl 52(%ebx),%edx <----
      0x087a57ab: movl %ebx,%eax
      0x087a57ad: testl %edx,%edx
      0x087a57af: jne 0x087a57c6 <0x87a57c6>
      0x087a57b5: pushl $0x8640314
      0x087a57ba: call 0x087a57bf <0x87a57bf>
      0x087a57bf: pushal
      0x087a57c0: call debug <0x840e7c0>
      0x087a57c5: hlt


      ucontext info:

      (/net/brandx/intel/tools/SUNWspro/SC5.0/WS5.0/bin/dbx.cmpx) c+36/20 X

      0x08ae5da0: gs:0x0000014f fs:0xfe9b0000 es:0x0000001f ds:0x08ac0
      01f
      0x08ae5db0: edi:0xc5f029f0 esi:0xda41c276 ebp:0xc5f029d4 esp:0xe
      ff93fe4
      0x08ae5dc0: ebx:0x7fffffec edx:0x0879a56d ecx:0xda4af5e0 eax:0xd
      a400140
      0x08ae5dd0: trapno:0x0000000e err:0x00000004 eip:0x087a57a8 cs:0
      x00000017
      0x08ae5de0: efl:0x00010246 uesp:0xc5f029ac ss:0x0000001f

      Where ebx:0x7fffffec is not referencable
      try find on 87a57a8: (the signal 11 address)

      "Executing find"
      239 fast_invokevtable [0x87a5758, 0x87a57dc[ 132 bytes not safepoi
      nt safe

      try find on 0x879a56d (the 4 repeat frames address)


      "Executing find"
      return entry points [0x879a450, 0x879a6a8[ 600 bytes not safepoint
       safe

      Try looking at the code that got into the 4 repeat frames


      0x0879a590: jmp *_active_table+0x400(,%ebx,4)
      0x0879a597: movl -20(%ebp),%esi
      0x0879a59a: movl -16(%ebp),%edi




        Attachments

          Activity

            People

            Assignee:
            acorn Karen Kinnear (Inactive)
            Reporter:
            acorn Karen Kinnear (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: