<AWT Dev> Endless loop in EventDispatchThread - proposed solution

[Artem Ananiev]

Hi, Clemens,

thanks to Anthony, your fix has been pushed into the JDK8 workspace:

http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d72ac458b2b7

Artem

On 9/14/2011 2:02 AM, Clemens Eisserer wrote:
> Hi again,
>
> If you are ok with the latest patch, could somebody please push it?
>
> Thanks, Clemens
>
>
> 2011/8/30 Clemens Eisserer <linuxhippy at gmail.com
> <mailto:linuxhippy at gmail.com>>
>
>     Hi Artem,
>
>         I'm fine with EventDispatchThread.java changes from the full
>         version. Are the pushPopLock.__isHeldByCurrentThread() checks
>         required, given that EDT.interrupt() is now respected?
>
>
>     The checks avoid hanging in case Thread.stop() has been called,
>     without Thread.interrupt() before, as you stated:
>
>
>         What if somebody calls EDT.stop() directly, without preceding
>         interrupt()? I understand this is not a typical scenario, and we
>         probably shouldn't support it, but we should at least not hang.
>
>
>
>     I prepared another patch, which does not require those checks to
>     avoid hanging, however it will print out an
>     IllegalMonitorStateException in the case stop() has been called,
>     without interrupt() before:
>     http://cr.openjdk.java.net/~ceisserer/7081670/webrev_full.05/
>     <http://cr.openjdk.java.net/%7Eceisserer/7081670/webrev_full.05/>
>
>     The patch with the checks in is located at:
>
>     http://cr.openjdk.java.net/~ceisserer/7081670/webrev_full.03/
>     <http://cr.openjdk.java.net/%7Eceisserer/7081670/webrev_full.03/>
>
>         Once approved, the fix should go to JDK8 workspace first. Then
>         it will be backported to JDK7u.
>
>     Perfect :)
>
>
>             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.
>
>
>     Its basically the same problem, there is a fixed timeout (5s) but
>     sun.awt.SunToolkit.realSync waits for 10s and then times out.
>     If I increase the timeout to 60s I get the same Exception as with
>     the other test:
>
>         sun.awt.SunToolkit$OperationTimedOut: 10932
>
>              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 Impl.run(LoopRobustness.java:114)
>              at java.lang.Thread.run(Thread.java:722)
>
>
>
>     Thanks, Clemens
>
>