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

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.