JDK-6893651 : Some of AWT_Modality/Automated/ tests hungs with XSession during execution
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6u17
  • Priority: P3
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2009-10-21
  • Updated: 2020-02-07
  • Resolved: 2020-02-07
Related Reports
Relates :  
JDK-6563771 - Erroneous window closing and complete workstation freeze up
Relates :  
JDK-7029467 - AWT test suite hangs on Solaris 11
Description
Testsuite name: AWT
JDK/JRE tested: 1.6.0_17
OS/architecture: Solaris 9 sun4u 64-bit
Reproducible: Sometimes
Reproducible on machine: stt-23.russia.sun.com
Also reproducible on machine: murcielago.russia.sun.com
Is it a platform specific regression: N 
Is it a Regression: Y
 Regression introduced in 1.6.0_17
Test results available at: /set/stt/newroot/results/1.6.0_17/b04_j4b/awt/solaris9_normal-sparcv9/1.6.0_17_b04_j4b_solaris9_normal-sparcv9_02
Running with CDE
During tests execution some of the tests hungs. Xwindows session no more response after that (See an http://vice.russia.sun.com//newroot/results/1.6.0_17/b04_j4b/awt/solaris9_normal-sparcv9/1.6.0_17_b04_j4b_solaris9_normal-sparcv9_02/screen-finish.jpg screenshot )

Not reproduced with Solaris10 Gnome
Comments
Cannot reproduce on the latest jdk
07-02-2020
EVALUATION Adfter discussion with SQE team I have the next update. During the tests execution "X server hangs". In fact the mouse could be used and the problem looks like a grab issue. The tests continue to execute after "the hang" The failures are most probably concerned with inability to interact with test windows. Despite this information from SQE log file http://vice.russia.sun.com//newroot/results/1.6.0_17/b04_j4b/awt/solaris9_normal-sparcv9/1.6.0_17_b04_j4b_solaris9_normal-sparcv9_02/tonga.output/Tonga.html shows that failed tests interlaced with passed tests. If the Xserver was hanged all test after certain time would be failed. I asked the SQE team to reproduce the issue to examine the X server behaviour after the hang.
25-11-2010
EVALUATION I extracted the test from the suit. The test attached to the CR as test_for_6893651.zip See CR 7002389 for other problems with the same tests.
25-11-2010
EVALUATION I reproduce this issue with options mentioned above
25-01-2010
EVALUATION Could you please try the following configuration: 1. Add the following line to your $HOME/.Xdefaults: Dtwm*secondariesOnTop: True 2. Then, restart gdm 3. Make sure that the option "Style Manager -> Window -> Allow Primary Windows On Top" is unchecked. By default, CDE may ignore TRANSIENT_FOR hint (http://monaco.sfbay/detail.jsf?cr=1236958) and this behaviour may break AWT modality. The hang isn't reproducible for me with the disabled option but I need someone to confirm (or deny) that disabling the option helps.
22-12-2009
EVALUATION The failure happens during the execution of the following tonga test: suites/6.0/awt/src/AWT_Modality/Automated/ModalBlocking/ToolkitModalDialog/Test2.java During the modal test execution DTWM (CDE window manager) becomes irresponsive (runs into infinite loop). This might be quite difficult to see the hang (when running the modal test remotely) as it usually takes many iterations of the modal test to run and even if DTWM runs into the infinite loop, the modal test continues its execution. A possible way to detect the hang is to get the dump of the DTWM process (pstack utility) and to check if the stack includes an entry corresponding to the FindTransientTreeLeader call. The "normal" state of the "alive" DTWM process (when no blocked windows) returns a stack without the FindTransientTreeLeader entry (attached run.ksh helps to detect the hang automatically). Interestingly that the infinite loop in DTWM is already known - CR http://monaco.sfbay/detail.jsf?cr=6563771 reported against jdk6. At the same time, the CR has been submitted as a regression. It looks like the only reasonable explanation to why the "tonga" failure is reproducible starting from 6u17 builds only is timing changes caused by any of the fixes integrated into 6u17. The reason for the infinite loop is that somehow AWT creates a circular chain of the TRANSIENT_FOR relationships. DTWM fails to handle correctly the circular chains. It's still not clear whether AWT is able to prevent building the circular chains. It requires further investigation. After looking at the modal test (Test2), the particular place where the hang occurs is: if (secondFrame != null) { secondFrame.setVisible(true); } if (secondDialog != null) { secondDialog.setVisible(true); } Introducing a short delay b/w the setVisible calls may help to workaround this issue.
20-11-2009
WORK AROUND Avoid showing several windows concurrently *** (#1 of 1): [ UNSAVED ] ###@###.###
20-11-2009
EVALUATION In my environment (6u17 b04 + CDE) this failure (hang) doesn't happen. The tests fail with some error messages (I guess that the failures are expected). Could you please provide additional info on this hang: >> Is it a Regression: Y Is the hang always reproducible with 6u17? Is the hang always non-reproducible with a release before 6u17? Which release? Could you please provide the thread dump for the hang using the following command: $JAVA_HOME/bin/jstack -l <pid> // replace <pid> with the actual pid of "hanged" java process
21-10-2009
EVALUATION Could you please specify the steps to reproduce the problem. Thanks.
21-10-2009