Multiple Event Dispatch Threads causing deadlock in Java Web Start app

Question

I am writing a Java Web Start application and I have observed it freezing. When I do a thread dump, I can see the two threads involved in the deadlock are both Event Dispatch Threads.

When I run the app locally, there is only one EDT, but when I download and run through Java Web Start, there is a second one.

Can someone tell me why there is a second EDT, and how can I prevent them deadlocking with each other?

edit: After monitoring the app using JVisualVM, I believe that the second EDT is responsible for redrawing the java console window.

Found one Java-level deadlock:
=============================
"AWT-EventQueue-1":
  waiting to lock monitor 0x07e4d8fc (object 0x29c2d950, a java.awt.Component$AWTTreeLock),
  which is held by "AWT-EventQueue-0"
"AWT-EventQueue-0":
  waiting to lock monitor 0x07e4cbfc (object 0x29c294e8, a java.lang.StringBuilder),
  which is held by "AWT-EventQueue-1"


Java stack information for the threads listed above:
===================================================
"AWT-EventQueue-1":
    at java.awt.Window.getOpacity(Unknown Source)
    - waiting to lock <0x29c2d950> (a java.awt.Component$AWTTreeLock)
    at sun.awt.SunToolkit.isContainingTopLevelTranslucent(Unknown Source)
    at sun.awt.windows.WComponentPeer.isAccelCapable(Unknown Source)
    at sun.java2d.d3d.D3DSurfaceData$D3DWindowSurfaceData.restoreSurface(Unknown Source)
    at sun.java2d.d3d.D3DScreenUpdateManager.validate(Unknown Source)
    at sun.java2d.d3d.D3DScreenUpdateManager.createGraphics(Unknown Source)
    at sun.awt.windows.WComponentPeer.getGraphics(Unknown Source)
    at java.awt.Component.getGraphics(Unknown Source)
    at javax.swing.JFrame.getGraphics(Unknown Source)
    at javax.swing.JComponent.safelyGetGraphics(Unknown Source)
    - locked <0x29c294e8> (a java.lang.StringBuilder)
    at javax.swing.RepaintManager$3.run(Unknown Source)
...
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.run(Unknown Source)
"AWT-EventQueue-0":
    at javax.swing.JComponent.isComponentObtainingGraphicsFrom(Unknown Source)
    - waiting to lock <0x29c294e8> (a java.lang.StringBuilder)
    at javax.swing.JComponent.getGraphicsInvoked(Unknown Source)
    at javax.swing.JFrame.getGraphics(Unknown Source)
...
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.run(Unknown Source)

Could it be: http://stackoverflow.com/questions/9795385/threading-and-deadlock-in-swing-application — assylias, May 29 '13 at 16:22
No. I am not creating my own EDT if that's what you're asking @assylias — birkner, May 29 '13 at 17:29

score 2 · Answer 1 · answered Jul 02 '13 at 19:19

we just had to find a issue which looks very much like yours.

Our findings: Java Webstart is triggering the creation of several EDT Threads. If you start your applet as application there is only a single EDT which would prevent the problem.

We could see activity on the second EDT only when we played around with the console window (resizing/ hiding). Resizing constantly made the problem reproducible very easily.

After a bit of hunting we could find a spot in our code where getGraphics was called within a paint method. This triggered a chain of calls ending on the very top of all components which seems to be shared with this console.

It is likely that this happens when the application and the console are open and the pc gets unlocked by its user as all components get redrawn at the same time.

Hope this helps. I would be interested in any additional detail about this mistery shared component.

Personally i would not suspect the console sharing a component with the main application that could lock each other in this way.

Good luck

score 1 · Answer 2 · answered Jun 28 '13 at 09:29

You are correct that the AWT-EventQueue-0 is your normal event thread and AWT-EventQueue-1 is a thread created when your application is started through Java web start. (Actually, you will find that the second one is created if your web start application doesn't display the console.)

As to the cause of the deadlock, it is impossible to say without seeing the full stack trace of the two threads, but there a few possiblities (in estimated decreasing order of probability!):

a bug in your video driver
a bug in your code
a bug in the JDK

Multiple Event Dispatch Threads causing deadlock in Java Web Start app

2 Answers2