Hi, Peter,
this issue, originally posted to NetBeans bugzilla, is tracked as
7159230 at bugs.sun.com:
http://bugs.sun.com/view_bug.do?bug_id=7159230
The reason of the deadlock is clear, but the scenario to reproduce it is
unknown. As I wrote in the evaluation, it's very weird to have a call to
EQ.detachDispatchThread() on NetBeans startup. That's why the bug is
still open (but AWT team is going to fix it anyway, just the priority is
not very high). Do you have a test case to reproduce it?
Thanks,
Artem
On 6/28/2012 11:33 AM, Peter Levart wrote:
This started as a bug report on the NetBeans bugzila:
http://netbeans.org/bugzilla/show_bug.cgi?id=214872
But is seems that it is caused by synchronization changes to
java.awt.EventQueue in JDK 1.7 (JDK 1.6 seems not to be affected).
To quote the part of the NetBeans bug:
I think that the root of the problem is in JDK 1.7, namely in the method:
java.awt.EventQueue.detachDispatchThread
...where it calls SunToolkit.isPostEventQueueEmpty() while holding global
"pushPopLock".
The static method SunToolkit.isPostEventQueueEmpty() invokes a synchronized
method on a singleton PostEventQueue object. Also other methods on this
singleton PostEventQueue are synchronized and some of them (for example
PostEventQueue.flush() invoked from static SunToolkit.flushPendingEvents()) are
also synchronized and call into the java.awt.EventQueue which tries to get the
global "pushPopLock" - hence the deadlock.
SunToolkit.isPostEventQueueEmpty() (or any of it's methods that delegate to
PostEventQueue singleton) should not be called while holding global
"pushPopLock" in java.awt.EventQueue...
My proposal to fix this bug is to rewrite the SunToolkit.PostEventQueue to use
the same global "pushPopLock" Lock instance that java.awt.EnetQueue uses for
it's synchronization instead of "synchronized" instance methods...
Regards, Peter
