RFR 8067241 DeadlockTest.java failed with negative timeout value
shanliang
shanliang.jiang at oracle.com
Fri Dec 12 08:56:35 UTC 2014
Daniel Fuchs wrote:
> Hi Shanliang,
>
> These two statements are no longer needed and should be removed - as they
> are misleading:
>
> 64 if (!bb.gotLock) {
> 65 throw new RuntimeException("Failed to get lock, impossible!");
> 66 }
>
>
> 81 if (!wb.done) {
> 82 throw new RuntimeException("It is blocked!");
> 83 }
>
Yes, can be removed.
>
>
> which makes me wonder whether your changes are deeper than intended.
> Now the test will either succeed, or fail in jtreg timeout. The condition
> "It is blocked!"
> can no longer be detected by the test. Is that your intention? If that's
> your intention - I guess it is OK - but maybe it would deserve a comment
> in the @summary of the test. Something like 'This bug attempts to
> reproduce
> a deadlock situation and will block forever if the deadlock is present.'
Updated.
Here is the new version:
http://cr.openjdk.java.net/~sjiang/JDK-8067241/01/
Thanks,
Shanliang
>
> best regards,
>
> -- daniel
>
> On 12/12/14 8:33 AM, shanliang wrote:
>> Hi,
>>
>> It is a test bug, it is not correct:
>> while(!wb.done || timeToWait > 0) {
>>
>> it should be:
>> while(!wb.done && timeToWait > 0) {
>>
>> || should be changed to &&
>>
>> Another issue is that the waiting time could be not enough (final
>> long timeout = 2000).
>>
>> The fix is to remove the waiting time specified in the test, the
>> timeout of test harness will be used as the max waiting time.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8067241
>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8067241/00/
>>
>> thanks,
>> Shanliang
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20141212/84e30919/attachment.html>
More information about the serviceability-dev
mailing list