(XS) RFR: 8152849: share/vm/runtime/mutex.cpp:1161 assert(((uintptr_t(_owner))|(uintptr_t(_LockWord.FullWord))|(uintptr_t(_EntryList))|(uintptr_t(_WaitSet))|(uintptr_t(_OnDeck))) == 0) failed

David Holmes david.holmes at oracle.com
Thu Aug 18 00:04:16 UTC 2016


Hi Dan,

Thanks for looking at this.

On 17/08/2016 10:59 PM, Daniel D. Daugherty wrote:
> On 8/17/16 1:45 AM, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152849
>>
>> webrev: http://cr.openjdk.java.net/~dholmes/8152849/webrev/
>
> src/share/vm/runtime/mutex.cpp
>     If the problem is a racy clearing of one of the fields, then the
>     assert can still fire and the extra info might still show zeroes
>     since they are two different queries of the fields.
>
>     For this diagnostic to be always accurate you need to save a copy
>     of each field, assert() that all the copies or'ed together are == 0,
>     and have the extra info printed from the copies.

You are right of course. Don't know what I was thinking. :(

http://cr.openjdk.java.net/~dholmes/8152849/webrev.v2/

Thanks,
David

> Dan
>
>
>>
>> This is a rare assertion failure that has proven to unreproducible
>> even by directly trying to exercise the theoretical race conditions
>> mentioned in the bug report. All I can do for now is augment the
>> assert to print out the various values so we can at least see where
>> things are failing, next time it happens.
>>
>> Example output:
>>
>> #  Internal Error
>> (/scratch/dh198349/jdk9-hs/hotspot/src/share/vm/runtime/mutex.cpp:1157),
>> pid=21732, tid=21734
>> #
>> assert(((uintptr_t(_owner))|(uintptr_t(_LockWord.FullWord))|(uintptr_t(_EntryList))|(uintptr_t(_WaitSet))|(uintptr_t(_OnDeck)))
>> == 0) failed:
>> _owner(0x0000000000000000)|_LockWord(0x0000000000000000)|_EntryList(0x0000000000000000)|_WaitSet(0x0000000000000000)|_OnDeck(0x00000000deaddead)
>> != 0
>>
>> Thanks,
>> David
>


More information about the hotspot-runtime-dev mailing list