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

(gc) VM crashes with sigsegv in markClassClass() in gc code

    Details

    • Subcomponent:
    • Introduced In Build:
      1.1.6
    • Introduced In Version:
    • Resolved In Build:
      b01
    • CPU:
      generic
    • OS:
      solaris_2.6
    • Verification:
      Verified

      Backports

        Description


        Customer's application is crashing randomly with the following stack trace...

        =>[1] markClassClass(0xef72d6a8, 0xed733330, 0x1, 0xef72d6c4,
          [2] markChildren(0xed733328, 0xed733330, 0x0, 0xef72d6a8, 0x1,
          [3] gc0_locked(0xef72d6ac, 0xef72d6a8, 0xef725080, 0xef72d354,
          [4] gc(0x0, 0xffffffff, 0xef731000, 0xef72d400, 0xef72d400,
          [5] Java_java_lang_Runtime_gc_stub(0x58edc4, 0xeb943c94, 0x0,
          [6] invokeNativeMethod(0x58ed9c, 0xbffc4, 0x58edc4, 0xeb943c94,
          [7] finish_invokevirtual(0x571c34, 0xeb943c94, 0x58edc4,
          [8] do_execute_java_method_vararg(0xeb943c94, 0xef72ac8d,
          [9] execute_java_dynamic_method(0xeb943c94, 0xed710288,
          [10] ThreadRT0(0xed710288, 0xef72ac8c, 0x22000, 0xef795240,
          [11] _start(0x0, 0xeb603d80, 0x0, 0xef79de90, 0x1, 0xfe401000


        Note that sometimes gc is also called as a result of a memory allocation
        failure.

        The crash was occuring in markChildren() because we were encountering
        a handle that was on the handle free list whilst scanning an
        object. (That is, object A referred to object B which had been
        freed in the previous gc). markChildren() does not detect that it is
        actually dealing with a handle on the free list and passes what it thinks
        is the object's classblock to markClassClass(). This value is actually 0
        and the VM crashes.

        So the question is how did object A end up referring to a handle that
        is on the free list.

        Debugging shows that object A was detected and marked in the previous gc;
        object B was not detected, and therefore freed in the previous gc.

        This appears to be the result of an edge-case when determining
        whether to recursively mark the children.

        In the prepareFinalization() function, we call markChildrenFromTop()
        with a limit of hpmax. prepareFinalization is called after scanHandles()
        so we are not going to be doing any more scanning after this.
        So we want to pass in a limit that guarantees we will always
        recursively mark the children of the object. hpmax works in
        every case except for a handle that is in the last slot
        in the handle array.

        In this case, limit = object A's handle when markchildren is called.
        markChildren() only does the recursion if the object's handle address
        is *less than* limit. In this case it would skip the recursive marking
        and any children refered to by object A (which were not already
        marked) will be freed.

        sandy.labrasca@eng 1999-01-12
        See more info...
        Put DMT in the program management field.

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  duke J. Duke (Inactive)
                  Reporter:
                  duke J. Duke (Inactive)
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:
                    Imported:
                    Indexed: