EVALUATION
After the fix for 6480378 integrated into JDK 5u13, the fix for this issue should be also backported to 5.0 update release.
|
|
|
SUGGESTED FIX
--- WCanvasPeer.java Fri Sep 23 13:37:17 2005
***************
*** 44,51 ****
* Up-called for other windows peer instances (WPanelPeer, WWindowPeer).
*/
public void displayChanged() {
! clearLocalGC();
! resetTargetGC();
super.displayChanged();
}
--- 44,53 ----
* Up-called for other windows peer instances (WPanelPeer, WWindowPeer).
*/
public void displayChanged() {
! synchronized (((Component)target).getTreeLock()) {
! clearLocalGC();
! resetTargetGC();
! }
super.displayChanged();
}
|
|
|
EVALUATION
The deadlock is really between two threads: EDT and main. One lock is AWT TreeLock, another one is native critical section used to synchronize all the calls to native objects from Java.
In more detail: when the window is moved to another screen, WWindowPeer.displayChanged() is called on EDT. Then it resets its target's GC by calling to native method resetTargetGC. This native method enters the critical section and then calls to Component.setGCFromPeer which requires treeLock. Another thread, main thread, in the same time moves the window by Component.setLocation() which acquires treeLock and calls to WComponentPeer.reshape(). That methos is also native and it tries to enter the critical section and hangs.
As all the GC changes in AWT shared code is done under the treeLock, we should add the same synchronization to the peer code that deals with GC. See suggested fix for details.
|
|
|
SUGGESTED FIX
The fix above really fixes the problem but it can be improved much. In fact, there is no need in native method at all, and the native critical section can be eliminated.
|
|
|
EVALUATION
After I modified the test to remove all of the 2d-related stuff I was
able to reproduce the deadlock easily.
I'll polish the test a bit more and attach it to the bugreport.
|
|
|
EVALUATION
After I've stripped the test from 2D-related code I was able to determine
that this is not a regression since b51, since I can reproduce it on b50 and
earlier builds, but the hang is with a little different stack trace, when
a new window is about to be created:
"main" prio=5 tid=0x00037200 nid=0x1e0 runnable [0x0007f000..0x0007fc24]
java.lang.Thread.State: RUNNABLE
at sun.awt.windows.WComponentPeer.endValidate(Native Method)
at java.awt.Container.validate(Container.java:1445)
- locked <0x02e51348> (a java.awt.Component$AWTTreeLock)
at MoveWindowVirtualScreenTest.createWindow(MoveWindowVirtualScreenTest.java:102)
at MoveWindowVirtualScreenTest.<init>(MoveWindowVirtualScreenTest.java:40)
at MoveWindowVirtualScreenTest.main(MoveWindowVirtualScreenTest.java:46)
"AWT-EventQueue-0" prio=7 tid=0x0aa67900 nid=0x698 waiting for monitor entry [0x0cd0f000..0x0cd0fb94]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.awt.Component.setGCFromPeer(Component.java:948)
- waiting to lock <0x02e51348> (a java.awt.Component$AWTTreeLock)
at java.awt.Window.resetGC(Window.java:2421)
at sun.awt.windows.WWindowPeer.resetTargetGC(Native Method)
at sun.awt.windows.WCanvasPeer.displayChanged(WCanvasPeer.java:48)
at sun.awt.windows.WPanelPeer.displayChanged(WPanelPeer.java:142)
at sun.awt.windows.WWindowPeer.displayChanged(WWindowPeer.java:273)
at sun.awt.windows.WWindowPeer$1.run(WWindowPeer.java:216)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
After the awt integration on 09/07/05 the test hangs more readily with the
window spanning across the screens.
This hang originally reported by this bug is likely to be caused by this fix
in awt integration:
5025858: Resizing a decorated frame triggers componentResized event twice
Webrev : http://sa.sfbay.sun.com/projects/awt_data/mustang/5025858/
It appears that the main thread attempts to execute stuff
on EDT (which is waiting for the treelock) while holding a treelock itself, thus a deadlock.
Prior to the fix for 5025858 we only attempted to do this if the window was
resized. But now we do this even if he size didn't change - thus the chances for
the deadlock are increased, which is the reason the test runs into this deadlock
more easily now.
|
|
|
EVALUATION
I've updated the test, and reassigned the bug to awt folks.
|
|
|
EVALUATION
I've tried the test on two different systems (with two nvidia boards,
and another with nvidia and ati rage 128 pro), but I can't reproduce
the bug.
Could the submitter please try to reproduce it on any other system?
(or ask sqe folks here in SCA to do it)
Looking at the stack trace it appears to be a deadlock between the
EventDispatchThread (which is waiting for the treelock) and the main
thread. So it may explain why I can't easily reproduce it.
This seems to be AWT problem. The test could probably be minimized not
to have any 2D-related things, just move the window back and forth.
Since the bug is not readily reproducible I'm changing the priority to P3.
|
|
|
EVALUATION
Please provide a stack trace of the hang if possible (Ctrl+Break).
|
|
|
Java