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