(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