<i18n dev> testcase failure java/util/Locale/Bug6989440.java

[Chris Hegarty]

Alan, David,

I noticed CR 7027061 was closed as 'not a defect'. Should I file a new 
CR to have the jtreg test fixed (join on all created threads)? The test 
will still exercise what it is supposed to, and the 
ConcurrentModificationException issue can be investigated at another 
time. This way we can get more stable test runs.

-Chris.

On 04/10/2011 17:04, David Holmes wrote:
> Thanks Chris and Alan.
>
> On 4/10/2011 11:24 PM, Alan Bateman wrote:
>> Chris Hegarty wrote:
>>> Trivially, should the main thread in the test be waiting on the three
>>> other threads to complete before exiting?
>>>
>>> I think jtreg will try to cleanup once the main thread completes. The
>>> main thread should keep an array of the threads it creates and invoke
>>> join() on each of them before returning from main. We do this all the
>>> time in other areas.
>> Right, once the main thread completes then jtreg will attempt to cleanup
>> the remaining non-daemon threads in the thread group. It does this by
>> interrupting each of the remaining threads in a loop up to a maximum
>> number of rounds or until the remaining threads have terminated.
>
> I wasn't aware of this behaviour from jtreg (but then I don't write such
> tests). It explains the jtreg "error". I expect the test threads are not
> responsive to interrupts (why should they be).
>
> The reported ConcurrentModificationException would indicate a potential
> issue still remaining in the locale code.
>
> David
>
> It's
>> possible that if the test is changed up to join on each of the 3 threads
>> that this intermittent failure will go away. If so, then it suggests to
>> me that perhaps the interrupt is causing a side effect that causes one
>> of the threads to go into a loop block uninterruptedly. This is just a
>> guess of course and it requires digging into the Locale code to come up
>> with specific theories.
>>
>> -Alan.