<AWT Dev> Endless loop in EventDispatchThread - proposed solution

[Artem Ananiev]

On 8/29/2011 11:36 PM, Clemens Eisserer wrote:
> Hi,
>
>     we had a short offline discussion with Oleg, and we both agree there
>     is no need to clear the event queue explicitly. If the interrupt()
>     call comes from AppContext.dispose(), a new EDT will not be
>     initialized (because of the check for AppContext.isDisposed() in
>     initDispatchThread()).
>
>
> Thanks, I updated both versions of the patch with the comment suggested
> by Dave (however my englisch is not perfect, so please feel free to
> modify it as you like):
> http://cr.openjdk.java.net/~ceisserer/7081670/webrev_full.03/
> http://cr.openjdk.java.net/~ceisserer/7081670/webrev_minimal.01/

I'm fine with EventDispatchThread.java changes from the full version. 
Are the pushPopLock.isHeldByCurrentThread() checks required, given that 
EDT.interrupt() is now respected?

> If the "full" version is considered too risky for JDK7, it would be
> great if the minimal could make it in, as caciocavallo-web gets bitten
> by this bug.

Once approved, the fix should go to JDK8 workspace first. Then it will 
be backported to JDK7u.

> The "minimal" version has a more extensive comment, as for the "minimal"
> version the check for isHeldByCurrentThread is not just cosmetic but
> required.
>
>     So your "full" version of the fix looks fine. As a sanity check,
>     please run all the tests from test/java/awt/EQ and test/java/awt/EDT
>     with your changes, it shouldn't take much time.
>
>
> I ran the tests, but EventDispatchThread/LoopRobustness fails with:
>
>     Caused by: java.lang.RuntimeException: Die, AWT-Event Queue thread!
>          at HostileCrasher.<clinit>(LoopRobustness.java:157)
>          ... 23 more
>     Exception in thread "main" java.lang.RuntimeException: Test FAILED:
>     second thread hasn't notified MainThread
>          at LoopRobustness.main(LoopRobustness.java:70)

Hmm... That's odd. The test passes on my Windows desktop. The first 
stack trace is printed to the console, but it's expected as 
e.printStackTrace() is called from the test. However, the second 
exception thrown from LoopRobustness.java:70 looks the real problem.

>   and HandleExceptionOnEDT seems to time out somehow:
>
>     Exception in thread "main" sun.awt.SunToolkit$OperationTimedOut: 10005
>          at sun.awt.X11.XToolkit.syncNativeQueue(XToolkit.java:2443)
>          at sun.awt.SunToolkit.realSync(SunToolkit.java:1580)
>          at sun.awt.SunToolkit.realSync(SunToolkit.java:1512)
>          at test.java.awt.regtesthelpers.Util.waitForIdle(Util.java:184)
>          at HandleExceptionOnEDT.main(HandleExceptionOnEDT.java:75)

realSync() is known to behave this way on some X11 systems. This failure 
doesn't seem to be caused by your fix.

> However, I get exatly the same behaviour with the proprietary release
> build of JDK7,
> so I guess those tests have been broken before. Are those tests executed
> before release?
>
> Thanks, Clemens

Thanks,

Artem