(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
Daniel D. Daugherty
daniel.daugherty at oracle.com
Thu Aug 18 14:04:51 UTC 2016
On 8/17/16 6:04 PM, David Holmes wrote:
> Hi Dan,
> Thanks for looking at this.
No problem. I'm pretty sure I once chased the older version
of this bug... :-)
> 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/
>> 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. :(
>>> 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
>>> pid=21732, tid=21734
>>> == 0) failed:
>>> != 0
More information about the hotspot-runtime-dev