<i18n dev> testcase failure java/util/Locale/Bug6989440.java
chris.hegarty at oracle.com
Wed Oct 5 07:07:00 PDT 2011
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.
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.
>> 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.
More information about the i18n-dev