JDK-6293929 : JAVA program hangs with XInitThreads call with JDK 5.0, but works with JDK1.4.2
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: linux
  • CPU: x86
  • Submitted: 2005-07-04
  • Updated: 2011-01-19
  • Resolved: 2006-03-13
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.5.0_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09)
Java HotSpot(TM) Client VM (build 1.5.0_02-b09, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Red Hat Linux ES
uname -a output:
Linux huff 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:52:56 EDT 2003 i686 i686 i386 GNU/Linux

A DESCRIPTION OF THE PROBLEM :
When a native library that calls XInitThreads() is loaded in a Java Swing application, the application hangs on interacting with the Swing components.

We need to load a native library that makes xlib calls. As documented in the XInitThreads man page, we make the call to XInitThreads() as the first xlib call in the process (by loading the library in the first line of the Java's main method.). Loading the native library causes the Java GUI code to become unstable and hang. If the library is not loaded the testcase works as expected.

The issue is similar to bugid 4908942  that was resolved in JDK 1.4.2_05. However, the bug has resurfaced on Java 1.5 on Linux.

A Java testcase(JFrameHang.java) with source code of the native library making the XInitThreads() call(xdll.cpp) is attached.



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile the native library (xdll.cpp) on Linux ES 3.0:

$ g++ -o libx.so -shared -Wl,-soname,libx.so -L/usr/X11R6/lib -I/usr/X11R6/include/X11 xdll.cpp -lX11

This will create libx.so in the current directory.

Ensure that the directory containing libs.so is in LD_LIBRARY_PATH environment variable:

$ export LD_LIBRARY_PATH=.

Compile and run the Java testcase:

$JAVA_HOME/javac JFrameHang.java

$JAVA_HOME/java JFrameHang


This will launch a JFrame containing a JButton. Click the button and resize the frame. Notice that with Java 1.5, the JFrame stops responding and painting itself. Closing the application does not work. Control+C cannot close the application as well. The process needs to be killed to terminate it.

On running the same application with Java 1.4.2_05, it works fine.



EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The JFrame should resize correctly, without causing a hang. Pressing the JButton should not cause the application to hang. Closing the application using the "X" button in the title bar should cause it to terminate gracefully and the application must not hang.
ACTUAL -
The Java application hangs on interaction (resizing, pressing buttons).

The JFrame stops responding and painting itself on resizing and clicking the contained JButton. Closing the application using the "X" button in the title bar does not work. Control+C cannot close the application as well. The process needs to be killed to terminate it.


ERROR MESSAGES/STACK TRACES THAT OCCUR :
No error message is displayed on the console. The application just hangs silently.

On sending a "kill -3 <pid>" the following log is generated:
 
"DestroyJavaVM" prio=1 tid=0x0805ab60 nid=0x2a5e waiting on condition [0x00000000..0xbfff8080]
 
"AWT-EventQueue-0" prio=1 tid=0x081ba138 nid=0x2a69 in Object.wait() [0x507af000..0x507af600]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x458fb060> (a java.awt.EventQueue)
        at java.lang.Object.wait(Object.java:474)
        at java.awt.EventQueue.getNextEvent(EventQueue.java:345)
        - locked <0x458fb060> (a java.awt.EventQueue)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:189)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)        at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
 
"AWT-Motif" daemon prio=1 tid=0x0819b4c8 nid=0x2a68 runnable [0x5072e000..0x5072e480]
        at sun.awt.motif.MToolkit.run(Native Method)
        at java.lang.Thread.run(Thread.java:595)
 
"AWT-Shutdown" prio=1 tid=0x0819afc8 nid=0x2a67 in Object.wait() [0x506ad000..0x506ad500]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x45987b68> (a java.lang.Object)
        at java.lang.Object.wait(Object.java:474)
        at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:259)
        - locked <0x45987b68> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:595)
 
"Java2D Disposer" daemon prio=1 tid=0x080f0c80 nid=0x2a66 in Object.wait() [0x5062c000..0x5062c780]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x459800e8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
        - locked <0x459800e8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
        at sun.java2d.Disposer.run(Disposer.java:107)
        at java.lang.Thread.run(Thread.java:595)
 
"Low Memory Detector" daemon prio=1 tid=0x080c4b00 nid=0x2a64 runnable [0x00000000..0x00000000]
 
"CompilerThread0" daemon prio=1 tid=0x080c3718 nid=0x2a63 waiting on condition [0x00000000..0x4f9fe0e8]
 
"Signal Dispatcher" daemon prio=1 tid=0x080c2788 nid=0x2a62 waiting on condition [0x00000000..0x00000000]
 
"Finalizer" daemon prio=1 tid=0x080b8cf8 nid=0x2a61 in Object.wait() [0x4f6fc000..0x4f6fc600]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x45980290> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
        - locked <0x45980290> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
 
"Reference Handler" daemon prio=1 tid=0x080b6f38 nid=0x2a60 in Object.wait() [0x4f67b000..0x4f67b480]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x45980310> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:474)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
        - locked <0x45980310> (a java.lang.ref.Reference$Lock)
 
"VM Thread" prio=1 tid=0x080b4308 nid=0x2a5f runnable
 
"VM Periodic Task Thread" prio=1 tid=0x080c6058 nid=0x2a65 waiting on condition
 
 



REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
//---------------------------------------------------------------------------------------------------
//JFrameHang.java
//---------------------------------------------------------------------------------------------------
import javax.swing.JFrame;

public class JFrameHang extends JFrame {
        public static void main(String[] args) {

                System.out.println("About to load DLL...\n");
                System.loadLibrary("x");
                System.out.println("Done loading...\n");

                System.out.println("About to create JFrame...");

                JFrame frame  = new JFrame();
                frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
                frame.getContentPane().add(new javax.swing.JButton("TEST"));
                frame.setSize(200,200);
                frame.setVisible(true);

                System.out.println("Done JFrame creation...");
        }
}

========================8<===============================

//--------------------------------------------------------------------------------------------------
//xdll.cpp
//--------------------------------------------------------------------------------------------------

#include <Xlib.h>
#include <stdio.h>

class a{
public:
  a() { XInitThreads(); }
};

a X;

========================8<===============================

#--------------------------------------------------------------------------------------------------
# run.sh
#--------------------------------------------------------------------------------------------------
if [ $1 == '1.5' ]
then
        JAVA_HOME=/home/test/jdk1.5.0_02/bin
else
        JAVA_HOME=/home/test/j2sdk1.4.2_05/bin
fi

$JAVA_HOME/javac JFrameHang.java
$JAVA_HOME/java JFrameHang

========================8<===============================

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
No known workaround.

Release Regression From : 5.0
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.
###@###.### 2005-07-04 12:59:09 GMT

Comments
EVALUATION I have to close the bug because there is no bug. There are two different toolkits. If you want to synchronize threads please use AWT methods for this.
13-03-2006

EVALUATION The bug is in Xlib. It was fixed (Patch id: 108652-93) for Xsun. To write Xlib multithread application you should use awtLock/awtUnlock methods instead of XInitThreads.
16-09-2005

EVALUATION Hangs with JDK5.0b64 and 6.0b42 with MToolkit or XToolkit on. GUI looks frozen but the window may be resized. There are no deadlocks. ###@###.### 2005-07-05 07:18:33 GMT I have tried to reproduce the problem on SuSE 9.2. vendor string: The X.Org Foundation vendor release number: 60801000 X.Org version: 6.8.1 The problem is not reproducible. But I easy reproduce the problem on my RH AS. The problem is in X implementation. It was fixed for 4908942 in 4985837 for Solaris. See 4985837 for more details. Please try to execute your program with 1.4.2_05. In a case your program will hang try to install another version of X library. If your program works fine with 1.4.2_05 but hangs with 5.0 please update this CR. ###@###.### 2005-07-11 12:02:59 GMT
05-07-2005