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

[Chris Hegarty]

David,

I'm not sure where we can file bugs on jtreg, probably have to wait for 
Jon to come back on line and drop him a mail.

This is even worse that I originally though. Any thread that throws an 
unchecked exception followed by another thread starting a thread ( or 
invoking any operation on the group requiring its monitor ) will 
encounter this hang. When run in samevm or agentvm mode.

Minimal treg test to reproduce this:

/*
  * @test
  */
import java.util.concurrent.Phaser;

public class HangJtreg {
     static Phaser phaser = new Phaser(2);

     public static void main(String[] args) throws Exception {
         (new Thread(new Runnable() {
             public void run() {
                 try {
                     throw new RuntimeException("thrown from 
ThrowingThread");
                 } finally {
                     phaser.arrive();
                 }
             }
         })).start();

         phaser.arriveAndAwaitAdvance();
         (new Thread()).start();
     }
}

-Chris.

On 10/11/11 12:00 AM, David Holmes wrote:
> So the jtreg uncaughtException code is doing a join() on the target
> Thread while holding the monitor lock of the ThreadGroup - ouch! Where
> do we file jtreg bugs?
>
> David
>
> On 11/10/2011 1:44 AM, Chris Hegarty wrote:
>> On 10/10/2011 15:52, Alan Bateman wrote:
>>> Chris Hegarty wrote:
>>>> Naoto,
>>>>
>>>> Forgot to add, you can probably just push the changes for the test
>>>> along with your source changes. I modified it a little since last
>>>> review. Reproduces one in about every ten times on one of our Dual
>>>> core Linux x64 boxes.
>>> Is it the CME that duplicates for you? I'm still wondering about the
>>> original failure mode which was a timeout, presumably a looping thread
>>> or deadlock or something else.
>>
>> This duplicates CME and deadlock. The deadlock would appear to happen
>> because jtreg tries to cleanup the thread that throws the CME, uncaught
>> exception. Look for 0xea769858 below.
>>
>> "Thread-7" prio=10 tid=0x0a026c00 nid=0x3c30 in Object.wait()
>> [0xd00fe000]
>> java.lang.Thread.State: TIMED_WAITING (on object monitor)
>> at java.lang.Object.wait(Native Method)
>> - waiting on <0xea769858> (a java.lang.Thread)
>> at java.lang.Thread.join(Thread.java:1266)
>> - locked <0xea769858> (a java.lang.Thread)
>> at
>> com.sun.javatest.regtest.MainAction$SameVMThreadGroup.cleanup(MainAction.java:760)
>>
>>
>> at
>> com.sun.javatest.regtest.MainAction$SameVMThreadGroup.uncaughtException(MainAction.java:727)
>>
>>
>> - locked <0xea766988> (a
>> com.sun.javatest.regtest.MainAction$SameVMThreadGroup)
>> at java.lang.Thread.dispatchUncaughtException(Thread.java:1964)
>>
>> "Thread-6" prio=10 tid=0x0a022000 nid=0x3c2f waiting for monitor entry
>> [0xd0256000]
>> java.lang.Thread.State: BLOCKED (on object monitor)
>> at java.lang.ThreadGroup.threadTerminated(ThreadGroup.java:942)
>> - waiting to lock <0xea766988> (a
>> com.sun.javatest.regtest.MainAction$SameVMThreadGroup)
>> at java.lang.Thread.exit(Thread.java:732)
>>
>> "SameVMThread" prio=10 tid=0xd058a000 nid=0x3c2e waiting for monitor
>> entry [0xd02a6000]
>> java.lang.Thread.State: BLOCKED (on object monitor)
>> at java.lang.ThreadGroup.add(ThreadGroup.java:885)
>> - waiting to lock <0xea766988> (a
>> com.sun.javatest.regtest.MainAction$SameVMThreadGroup)
>> at java.lang.Thread.start(Thread.java:687)
>> - locked <0xea790160> (a Bug6989440$TestThread)
>> at Bug6989440.main(Bug6989440.java:47)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>
>>
>> at java.lang.reflect.Method.invoke(Method.java:601)
>> at
>> com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:680)
>>
>> at java.lang.Thread.run(Thread.java:722)
>> .....
>>
>>
>> -Chris.
>>
>>>
>>> -Alan.