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

[Naoto Sato]

Looks good to me. Thanks!

Naoto

On 10/5/11 8:42 AM, Chris Hegarty wrote:
> Alan, Naoto, David
>
> I filed CR 7098100: java/util/Locale/Bug6989440.java fails intermittently.
>
> If you're ok with it please review the patch (below) and I can push it
> to the tl repo. Job done!
>
>  >: hg diff test/java/util/Locale/Bug6989440.java
> diff -r 24741fe639a8 test/java/util/Locale/Bug6989440.java
> --- a/test/java/util/Locale/Bug6989440.java Tue Oct 04 16:37:08 2011 +0100
> +++ b/test/java/util/Locale/Bug6989440.java Wed Oct 05 16:34:09 2011 +0100
> @@ -37,14 +37,15 @@ import sun.util.LocaleServiceProviderPoo
> import sun.util.LocaleServiceProviderPool;
>
> public class Bug6989440 {
> - public static void main(String[] args) {
> - TestThread t1 = new TestThread(LocaleNameProvider.class);
> - TestThread t2 = new TestThread(TimeZoneNameProvider.class);
> - TestThread t3 = new TestThread(DateFormatProvider.class);
> -
> - t1.start();
> - t2.start();
> - t3.start();
> + public static void main(String[] args) throws Exception {
> + Thread[] threads = new Thread[3];
> + threads[0] = new TestThread(LocaleNameProvider.class);
> + threads[1] = new TestThread(TimeZoneNameProvider.class);
> + threads[2] = new TestThread(DateFormatProvider.class);
> + for (int i=0; i<threads.length; i++)
> + threads[i].start();
> + for (int i=0; i<threads.length; i++)
> + threads[i].join();
> }
>
>
> -Chris.
>
>
> On 05/10/2011 15:57, Naoto Sato wrote:
>> Hi Chris,
>>
>> I appreciate it, and will fix the test case.
>>
>> Naoto
>>
>> On 10/5/11 7:07 AM, Chris Hegarty wrote:
>>> 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.
>>