RFR for JDK-6772009 Intermittent test failure: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2'

srikalyan chandrashekar srikalyan.chandrashekar at oracle.com
Wed Nov 20 02:39:54 UTC 2013


Hi Martin, i incorporated the recent changes from the pointer as well. I 
have reproduced the failure, the logs of which are attached to the bug 
JDK-6772009 <https://bugs.openjdk.java.net/browse/JDK-6772009> . The 
failed log is especially interesting .

--
Thanks
kalyan

On 11/18/13 10:15 PM, Martin Buchholz wrote:
> Thanks for working on this.
> There have been some recent upstream changes to this test as well. 
>  Please incorporate them.
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/jtreg/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java?view=co
> The jsr166 maintainers haven't been able to reproduce any failures in 
> this test.  Do you have any hints that might help us?
>
>
>
> On Mon, Nov 18, 2013 at 10:12 PM, srikalyan chandrashekar 
> <srikalyan.chandrashekar at oracle.com 
> <mailto:srikalyan.chandrashekar at oracle.com>> wrote:
>
>     Hi all, I am working on bug JDK-6772009
>     <https://bugs.openjdk.java.net/browse/JDK-6772009> .
>
>     Root Cause:
>     The timeout value gives too much grace period on faster machines
>     on which the "TO BE INTERRUPTED" threads complete faster before
>     being interrupted at right time.
>
>     Suggested Fix:
>     a) Decrease the timeout from 100 to 50ms which will ensure that
>     the test will pass even on faster machines , and ensures the
>     threads will be canceled when running and anyways there is a
>     Barrier to ensure the test threads all complete gracefully.
>     Miscellaneous fixes
>     b) Convert result from int to long(possible integer overflow
>     otherwise)
>     c) Catch BrokenBarrierException in more granular fashion in
>     ReentrantLockLoop to update and print the results (which will be
>     missed otherwise)
>     Add more diagnostics
>     d) Assign names to threads
>     e) Print which threads update the 'completed' variable.
>
>     I have attached the webrev for convenience as the changes are
>     interleaved and is best viewed as sdiff.
>     Please let me know if you have any comments or suggestions.
>
>
>
>     Thank you
>
>     -- 
>
>     --
>     Thanks
>     kalyan
>
>




More information about the core-libs-dev mailing list