JDK-6271779 : PIT. Displaying dialogs causes application hang
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_10
  • CPU: generic,sparc
  • Submitted: 2005-05-17
  • Updated: 2011-01-19
  • Resolved: 2005-07-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b43Fixed
Related Reports
Duplicate :  
JDK-6273041 - Regression test java/awt/Modal/BlockedMouseInputTest/BlockedMouseInputTest.html fails on Solaris
Duplicate :  
JDK-6271892 - PIT: Application hangs on Solaris after opening few dialogs
Description
This occurs on Solaris/Linux on AWT PIT build for mustang b38

java version "1.6.0-awt.pit-int-jcg-win-03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-awt.pit-int-jcg-win-03-java2d_06_may_2005_09_06-b00)
Java HotSpot(TM) Client VM (build 1.6.0-ea-b35, mixed mode)

Application freezes when Dialogs are repeatedly displayed and hidden

To reproduce, run the attached testcase and follow the steps:
1. The testcase displays a Frame with a button Show Dialog. Click the button
2. A dialog is shown. Click the Show Dialog button on the Dialog
3. Another dialog (dialog2) will be shown. Close it and click the Show Dialog button of Dialog1 again.
4. Close dialog2 and try to open it again by clicking the Show Dialog button of Dialog1. Now the application freezes.

Also, it can be noted that once Dialog2 is closed and reopened, modality is broken - Dialog1 can appear on top of Dialog2

The same behavior occurs whether the parent of the Dialogs is Frame or null
###@###.### 2005-05-17 16:39:55 GMT
Comments
EVALUATION Reproduced on JDS "AWT-EventQueue-0" prio=10 tid=0x001ace60 nid=0xf runnable [0xc63fe000..0xc63ff8 a0] at sun.awt.X11.XWindowPeer.addToTransientFors(XWindowPeer.java:999) - waiting to lock <0xfa9a8cc8> (a sun.awt.X11.XDialogPeer) ###@###.### 2005-05-19 11:25:00 GMT Looks like a lock-wait but following synchronized blocks works fine: setReparented setModalBlocked. Appearing this bug after repeated actions give n idea of adding same elements into one structure: Vector toplevels. ###@###.### 2005-05-19 13:51:39 GMT The problem is caused by wrong behaviour of XWindowPeer/XDialogPeer.removeFromTransientFors. All the windows and modeless dialogs are simply removed from the blocker's chain, and modal dialogs are left in the chain to prevent destroying their own chains. This should be rewritten, so when a modal dialog is unblocked, the chain is splitted into two subchains (the reverse process to addToTransientFors). ###@###.### 2005-05-23 10:16:58 GMT
19-05-2005