RFR: 8019948: java/util/logging/bundlesearch/ResourceBundleSearchTest.java is failing intermitently

David Holmes david.holmes at oracle.com
Thu Jul 25 04:47:41 UTC 2013


On 24/07/2013 11:07 PM, Daniel Fuchs wrote:
> Hi David,
>
> On 7/24/13 1:48 PM, David Holmes wrote:
>> On 23/07/2013 11:08 PM, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> Please find below a changeset for fixing
>>> 8019948: java/util/logging/bundlesearch/ResourceBundleSearchTest.java is
>>> failing intermittently [1]
>>>
>>> This appears to be a test bug due to a bizarre use of synchronization
>>> in the test. The test was failing regularly before the fix (= often
>>> enough), but I haven't managed to reproduce since I changed
>>> lr.wait() into lr.join();
>>
>> lr.join() is lr.wait() behind the scenes but with a check for isAlive().
>> So this suggests you have been getting spurious wakeups from lr.wait() -
>> which is theoretically possible but extremely unlikely. If you have the
>> cycles could you run the original code with this change:
>>
>>     lr.wait();
>> +  if (lr.isAlive()) throw new Error("Spurious wakeup!");
>
> As far as I can tell the issue seems to be that the caller never
> exit from its call to lr.wait().
>
> I am thinking  that maybe the thread is already finished when
> lr.wait() is called - so that the caller would never wake up,
> (it would have missed the notify()).

Yes of course. Use of wait() must always be guarded by the condition 
that is being waited upon.

Thanks,
David

> Increasing the load on the machine seemed to increase the chances of
> triggering the issue - which seems a usual pattern with these race
> conditions...
>
> best regards,
>
> -- daniel
>
>
>>
>> Thanks,
>> David
>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8019948/webrev.00/
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> [1] https://jbs.oracle.com/bugs/browse/JDK-8019948
>



More information about the core-libs-dev mailing list