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

assertion failure in share/vm/runtime/mutex.cpp:1119

    Details

    • Subcomponent:
    • CPU:
      generic
    • OS:
      generic

      Description

      Nightly test

      nsk/jdb/wherei/wherei001

      failed with an assertion

      # Internal Error (/tmp/jprt-jprtadm/P1/B/172814.iv159533/source/src/share/vm/runtime/mutex.cpp:1119), pid=389, tid=2887244688
      # Error: assert(((uintptr_t(_owner))|(uintptr_t(_LockWord.FullWord))|(uintptr_t(_EntryList))|(uintptr_t(_WaitSet))|(uintptr_t(_OnDeck))) == 0,"")
      #

      on linux x86
      This assertion failure was seen during testing of the fix for
      6876794 using the suspend/resume stress kit by the
      MultiBreakpointsTest:

          Internal Error (src/share/vm/runtime/mutex.cpp:1119)
          assert(((uintptr_t(_owner))|(uintptr_t(_LockWord.FullWord))|
            (uintptr_t(_EntryList))|(uintptr_t(_WaitSet))|
            (uintptr_t(_OnDeck))) == 0,"")

      The bits under test are:

          java version "1.7.0-ea"
          Java(TM) SE Runtime Environment (build 1.7.0-ea-b71)
          Java HotSpot(TM) Client VM (build 17.0-b01-internal-fastdebug, mixed mode)
          Java HotSpot(TM) Client VM (17.0-b01-internal-fastdebug) for solaris-x86 JRE (1.7.0), built on Sep 2 2009 16:48:02 by "dcubed" with Workshop 5.9

      so JDK7-B71 JDK bits plus an HSX-17-B01 VM plus additional
      changes plus the fix for 6876794. Here is the interesting
      part of the stack trace:

        [7] report_assertion_failure(file_name = ???, line_no = ???, message = ???) (optimized), at 0xfd507361 (line ~173) in "debug.cpp"
        [8] Monitor::~Monitor(this = ???) (optimized), at 0xfdd9c6ea (line ~1120) in "mutex.cpp"
        [9] Thread::~Thread(this = ???) (optimized), at 0xfe036578 (line ~231) in "thread.cpp"
        [10] JavaThread::~JavaThread(this = ???) (optimized), at 0xfe03d2e2 (line ~1290) in "thread.cpp"
        [11] __SLIP.DELETER__A(this = ???, delete = ???) (optimized), at 0xfe04ddd6 (line ~1290) in "thread.cpp"
        [12] JavaThread::thread_main_inner(this = ???) (optimized), at 0xfe03db97 (line ~1386) in "thread.cpp"
        [13] JavaThread::run(this = ???) (optimized), at 0xfe03d6d5 (line ~1364) in "thread.cpp"
        [14] java_start(thread_addr = ???) (optimized), at 0xfde018d3 (line ~1019) in
      "os_solaris.cpp"
        [15] _thr_setup(0xfceb6a00), at 0xfeec59b9
        [16] _lwp_start(0xf, 0x6, 0xfef3c000, 0xf2586bec, 0xfee71d73, 0xf), at 0xfeec5ca0

      I've attached the complete thread dump as threads.log.19288.
      doit.log.19288 and hs_err_pid.log.19288 are also attached.

      Update: Here is a summary of the suspend/resume stress testing:

      sol-x86-b71-c1-fast:
          CPUSampling 10204P/0I/0F (done) Java2Demo 165P/0I/0F (done) MTBPS 25726P/0I/1F (done) PepTest 29138P/0I/0F (done)
      sol-x86-b71-c1-prod:
          CPUSampling 11435P/0I/0F (done) Java2Demo 169P/0I/0F (done) MTBPS 31896P/0I/0F PepTest 45364P/0I/0F (done)
      sol-x86-b71-c2-fast:
          CPUSampling 10651P/0I/0F (done) Java2Demo 182P/0I/0F (done) MTBPS 14277P/0I/0F (done) PepTest 9925P/0I/0F (done)
      sol-x86-b71-c2-prod:
          CPUSampling 17317P/0I/0F (done) Java2Demo 190P/0I/0F (done) MTBPS 26910P/0I/0F (done) PepTest 20142P/0I/0F (done)

      Note that the failure I logged above occurred once in 25726 runs
      of the MultiBreakpointsTest over 24 hours on one of four configs.
      Pretty rare and definitely not the way to reproduce this bug.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                dcubed Daniel Daugherty
                Reporter:
                jmasa Jon Masamitsu (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: