FULL PRODUCT VERSION :
[  xxxxx@xxxxx   tester]$ java -version
java version "1.3.1_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_02-b02)
Java HotSpot(TM) Client VM (build 1.3.1_02-b02, mixed mode)


FULL OPERATING SYSTEM VERSION :

[  xxxxx@xxxxx   nsharp]$ uname -a
Linux legacy. customer -int.com 2.2.12-20 #1 Mon Sep 27 10:40:35 EDT 1999 i686 unknown

[  xxxxx@xxxxx   nsharp]# rpm -q glibc
glibc-2.1.2-11

 customer  6.1



ADDITIONAL OPERATING SYSTEMS :

Does not repeat on SGI or Windows(obviously)


EXTRA RELEVANT SYSTEM CONFIGURATION :
[  xxxxx@xxxxx   nsharp]# rpm -q -a | grep -i xfree
XFree86-3.3.5-3
XFree86-libs-3.3.5-3
XFree86-xfs-3.3.5-3
XFree86-75dpi-fonts-3.3.5-3
XFree86-SVGA-3.3.5-3
XFree86-devel-3.3.5-3


[  xxxxx@xxxxx   nsharp]# rpm -q -a | grep -i gnome
gnome-audio-1.0.0-7
gnome-audio-extra-1.0.0-7
gnome-core-1.0.39-10
gnome-core-devel-1.0.39-10
gnome-games-1.0.40-2
gnome-games-devel-1.0.40-2
gnome-libs-1.0.40-1
gnome-libs-devel-1.0.40-1
gnome-linuxconf-0.23-1
gnome-media-1.0.40-3
gnome-objc-1.0.2-5
gnome-objc-devel-1.0.2-5
gnome-pim-1.0.10-1
gnome-pim-devel-1.0.10-1
gnome-users-guide-1.0.7-1
gnome-utils-1.0.13-1
pygnome-1.0.4-2
switchdesk-gnome-1.7.1-1


A DESCRIPTION OF THE PROBLEM :
If you force the library libXt.so to preload, java will crash the first time you try to use an AWT window (Frame).

We are attempting to call java from a C++ program using the JNI invocation architecture.  The program works great on both our SGI and Windows ports but crashes badly on Linux.  We think we've isolated the problem to the fact that libXt is preloaded but can't find any workarounds.


Here is my sample program:
[  xxxxx@xxxxx   java]$ cat bla.java
import java.awt.*;

public class bla
{
 public static void main(String[] args)
  throws Exception
{
 System.out.println("HELLO!");
 Frame f = new Frame();
 f.show();
 f.hide();
 System.out.println("FRED!");
}
}

Here is my command to run it and what happens:
[  xxxxx@xxxxx   java]$ LD_PRELOAD=/usr/X11R6/lib/libXt.so java -cp . bla
HELLO!

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x49b1632d
Function name=_XmAddHashEntry
Library=/usr/java/jre/lib/i386/libawt.so

Current Java thread:
        at sun.awt.motif.MWindowPeer.create(Native Method)
        at sun.awt.motif.MComponentPeer.init(MComponentPeer.java:169)
        at sun.awt.motif.MWindowPeer.init(MWindowPeer.java:86)
        at sun.awt.motif.MFramePeer.<init>(MFramePeer.java:53)
        at sun.awt.motif.MToolkit.createFrame(MToolkit.java:138)
        at java.awt.Frame.addNotify(Frame.java:353)
        at java.awt.Window.show(Window.java:389)
        at bla.main(bla.java:12)

Dynamic libraries:
08048000-0804c000 r-xp 00000000 03:01 79929      /usr/java/bin/i386/native_threads/java
0804c000-0804d000 rw-p 00003000 03:01 79929      /usr/java/bin/i386/native_threads/java
40000000-40012000 r-xp 00000000 03:01 102402     /lib/ld-2.1.2.so
40012000-40013000 rw-p 00012000 03:01 102402     /lib/ld-2.1.2.so
40014000-4005c000 r-xp 00000000 03:01 15297      /usr/X11R6/lib/libXt.so.6.0
4005c000-40060000 rw-p 00047000 03:01 15297      /usr/X11R6/lib/libXt.so.6.0
40060000-40063000 r--p 00000000 03:01 73203      /usr/share/locale/en_US/LC_CTYPE
40063000-40064000 r--p 00000000 03:01 73205      /usr/share/locale/en_US/LC_MESSAGES/SYS_LC_MESSAGES
40064000-40065000 r--p 00000000 03:01 73206      /usr/share/locale/en_US/LC_MONETARY
40065000-4006f000 r-xp 00000000 03:01 102448     /lib/libpthread-0.8.so
4006f000-40076000 rw-p 00009000 03:01 102448     /lib/libpthread-0.8.so
40076000-4007f000 r-xp 00000000 03:01 21416      /usr/java/jre/lib/i386/native_threads/libhpi.so
4007f000-40080000 rw-p 00008000 03:01 21416      /usr/java/jre/lib/i386/native_threads/libhpi.so
40080000-40270000 r-xp 00000000 03:01 123669     /usr/java/jre/lib/i386/client/libjvm.so
40270000-4036e000 rw-p 001ef000 03:01 123669     /usr/java/jre/lib/i386/client/libjvm.so
40385000-40387000 r-xp 00000000 03:01 102418     /lib/libdl-2.1.2.so
40387000-40388000 rw-p 00001000 03:01 102418     /lib/libdl-2.1.2.so
40388000-40473000 r-xp 00000000 03:01 102409     /lib/libc-2.1.2.so
40473000-40477000 rw-p 000ea000 03:01 102409     /lib/libc-2.1.2.so
4047c000-4051a000 r-xp 00000000 03:01 15283      /usr/X11R6/lib/libX11.so.6.1
4051a000-40520000 rw-p 0009d000 03:01 15283      /usr/X11R6/lib/libX11.so.6.1
40520000-40528000 r-xp 00000000 03:01 15281      /usr/X11R6/lib/libSM.so.6.0
40528000-40529000 rw-p 00007000 03:01 15281      /usr/X11R6/lib/libSM.so.6.0
40529000-4053d000 r-xp 00000000 03:01 15277      /usr/X11R6/lib/libICE.so.6.3
4053d000-4053e000 rw-p 00013000 03:01 15277      /usr/X11R6/lib/libICE.so.6.3
40540000-40552000 r-xp 00000000 03:01 102422     /lib/libnsl-2.1.2.so
40552000-40553000 rw-p 00011000 03:01 102422     /lib/libnsl-2.1.2.so
40556000-40571000 r-xp 00000000 03:01 102420     /lib/libm-2.1.2.so
40571000-40572000 rw-p 0001a000 03:01 102420     /lib/libm-2.1.2.so
40572000-405a6000 r-xp 00000000 03:01 103177     /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so
405a6000-405b2000 rw-p 00033000 03:01 103177     /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so
405b5000-405c6000 r-xp 00000000 03:01 21418      /usr/java/jre/lib/i386/libverify.so
405c6000-405c8000 rw-p 00010000 03:01 21418      /usr/java/jre/lib/i386/libverify.so
405c8000-405e9000 r-xp 00000000 03:01 21419      /usr/java/jre/lib/i386/libjava.so
405e9000-405eb000 rw-p 00020000 03:01 21419      /usr/java/jre/lib/i386/libjava.so
405ec000-40600000 r-xp 00000000 03:01 21420      /usr/java/jre/lib/i386/libzip.so
40600000-40603000 rw-p 00013000 03:01 21420      /usr/java/jre/lib/i386/libzip.so
40603000-41334000 r--s 00000000 03:01 21449      /usr/java/jre/lib/rt.jar
41361000-41606000 r--s 00000000 03:01 21450      /usr/java/jre/lib/i18n.jar
41606000-4161c000 r--s 00000000 03:01 21437      /usr/java/jre/lib/sunrsasign.jar
436c4000-436cc000 r--p 00000000 03:01 73202      /usr/share/locale/en_US/LC_COLLATE
436cc000-436cd000 r--p 00000000 03:01 73208      /usr/share/locale/en_US/LC_TIME
436cd000-436ce000 r--p 00000000 03:01 73207      /usr/share/locale/en_US/LC_NUMERIC
4972f000-49733000 r-xp 00000000 03:01 15299      /usr/X11R6/lib/libXtst.so.6.1
49733000-49734000 rw-p 00003000 03:01 15299      /usr/X11R6/lib/libXtst.so.6.1
49734000-4973c000 r-xp 00000000 03:01 102440     /lib/libnss_files-2.1.2.so
4973c000-4973d000 rw-p 00007000 03:01 102440     /lib/libnss_files-2.1.2.so
497a9000-49b77000 r-xp 00000000 03:01 21427      /usr/java/jre/lib/i386/libawt.so
49b77000-49b87000 rw-p 003cd000 03:01 21427      /usr/java/jre/lib/i386/libawt.so
49b9c000-49bcd000 r-xp 00000000 03:01 21426      /usr/java/jre/lib/i386/libmlib_image.so
49bcd000-49bcf000 rw-p 00030000 03:01 21426      /usr/java/jre/lib/i386/libmlib_image.so
49bcf000-49bd5000 r-xp 00000000 03:01 15295      /usr/X11R6/lib/libXp.so.6.2
49bd5000-49bd6000 rw-p 00005000 03:01 15295      /usr/X11R6/lib/libXp.so.6.2
49bd6000-49be0000 r-xp 00000000 03:01 15289      /usr/X11R6/lib/libXext.so.6.3
49be0000-49be2000 rw-p 00009000 03:01 15289      /usr/X11R6/lib/libXext.so.6.3
49be2000-49c6c000 r-xp 00000000 03:01 21428      /usr/java/jre/lib/i386/libfontmanager.so
49c6c000-49c7c000 rw-p 00089000 03:01 21428      /usr/java/jre/lib/i386/libfontmanager.so
49c81000-49c8a000 r-xp 00000000 03:01 102446     /lib/libnss_nisplus-2.1.2.so
49c8a000-49c8b000 rw-p 00008000 03:01 102446     /lib/libnss_nisplus-2.1.2.so
49c8b000-49c93000 r-xp 00000000 03:01 102444     /lib/libnss_nis-2.1.2.so
49c93000-49c94000 rw-p 00007000 03:01 102444     /lib/libnss_nis-2.1.2.so
49c94000-49c97000 r-xp 00000000 03:01 102438     /lib/libnss_dns-2.1.2.so
49c97000-49c98000 rw-p 00002000 03:01 102438     /lib/libnss_dns-2.1.2.so
49c98000-49ca3000 r-xp 00000000 03:01 102450     /lib/libresolv-2.1.2.so
49ca3000-49ca5000 rw-p 0000a000 03:01 102450     /lib/libresolv-2.1.2.so

Local Time = Thu Feb 14 17:01:37 2002
Elapsed Time = 1
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.3.1_02-b02 mixed mode)
#
# An error report file has been saved as hs_err_pid5958.log.
# Please refer to the file for further information.
#



Thanks for your time!

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.
Read description
2.
Enter bla.java program from above.
3. compile program
4. Issue command found above and crash!

EXPECTED VERSUS ACTUAL BEHAVIOR :
See dump above in description

ERROR MESSAGES/STACK TRACES THAT OCCUR :
See description above

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
See description
---------- END SOURCE ----------

CUSTOMER WORKAROUND :
Need one badly
(Review ID: 139708) 
======================================================================




FULL PRODUCT VERSION :
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)

The bug also happens in

java version "1.4.0-beta3"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta3-b81)
Java HotSpot(TM) Client VM (build 1.4.0-beta3-b81, mixed mode)



FULL OPERATING SYSTEM VERSION :

SunOS arien 5.7 Generic_106541-16 sun4u sparc SUNW,Ultra-5_1


A DESCRIPTION OF THE PROBLEM :
We have native library that defines JNI_OnLoad.
We preload this library into a java process using
LD_PRELOAD, and then run a java program that requires AWT.
When the jvm gets around to loading the AWT native
components we get an UnsatisfiedLinkError.



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Build native lib defining JNI_OnLoad.
2. Write java app that requires AWT.
3. Launch java using LD_PRELOAD to preload the native lib.

EXPECTED VERSUS ACTUAL BEHAVIOR :
The exception is unexpected and doesn't happen if
we do not use LD_PRELOAD.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "main" java.lang.UnsatisfiedLinkError: exception occurred
in JNI_OnLoad
	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1382)
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1298)
	at java.lang.Runtime.loadLibrary0(Runtime.java:749)
	at java.lang.System.loadLibrary(System.java:820)
	at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:53)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.awt.NativeLibLoader.loadLibraries(NativeLibLoader.java:41)
	at sun.awt.DebugHelper.<clinit>(DebugHelper.java:29)
	at java.awt.Component.<clinit>(Component.java:356)

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Java code:

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

public class bug {
    public static void main(String s[]) {
        JFrame frame = new JFrame("TopLevelDemo");

        frame.addWindowListener(new WindowAdapter() {
            public void windowClosing(WindowEvent e) {
                System.exit(0);
            }
        });

        JLabel yellowLabel = new JLabel("");
        yellowLabel.setOpaque(true);
        yellowLabel.setBackground(Color.yellow);
        yellowLabel.setPreferredSize(new Dimension(200, 180));

        JMenuBar cyanMenuBar = new JMenuBar();
        cyanMenuBar.setOpaque(true);
        cyanMenuBar.setBackground(Color.cyan);
        cyanMenuBar.setPreferredSize(new Dimension(200, 20));

        frame.setJMenuBar(cyanMenuBar);
        frame.getContentPane().add(yellowLabel, BorderLayout.CENTER);

        frame.pack();
        frame.setVisible(true);
    }

}

Native code:

#include <jni.h>

JNIEXPORT jint JNICALL
JNI_OnLoad(JavaVM * jvm, void * reserved)
{ 
   return JNI_VERSION_1_2;
}

It appears that awt inadvertently captures the JNI_OnLoad
address provided by the preloaded library, passes that to dladdr, and uses
the resulting module path to find other 'nearby' libraries like motif. In
awt_LoadLibrary.c in the 1.3 sources, we see:

JNI_OnLoad()
{
    ...
    dladdr((void *)JNI_OnLoad, &dlinfo);
    ...
}

One might imagine that the reference to JNI_OnLoad in the call to dladdr
would always resolve to the address of the function containing the call to
dladdr, but that's not the case; if the  customer  JNI_OnLoad is exported you'll
get whatever it resolves to at dynamic loading time, which in this case is
within the preloaded library.

---------- END SOURCE ----------
(Review ID: 138379)
======================================================================
Posted Date : 2005-12-30 11:58:51.0

N/A

Commit to fix in mantis (crash).  Actually, it would be nice to fix this in 
Hopper if it goes along with the makefile work we are doing.  
  xxxxx@xxxxx   2002-02-19

Committing to hopper.  This is very closely related to 4618324.  When the makefile changes for headless were introduced in linux, it was found that libXt.so was being loaded by the plugin before libXm.so, which is not allowed (reason yet unknown), and causes AWT to crash.  It may not be possible to allow libXt.so to be pre-loaded before motif without removing the dependency on motif altogether (which is a goal for tiger), but a number of runtime library dependencies are being changed for hopper, which may directly affect this.
  xxxxx@xxxxx   2002-02-20

This is not fixable without removing motif support completely.  Decommitting from hopper, committing to tiger.
In Mustang default toolkit for both solaris and linux is XToolkit, which doesn't use libXm.so. Moreover, if we force MToolkit to be used, no crash happens but an exception is thrown instead:

Exception in thread "main" java.lang.InternalError: libXt loaded before libXm

The reason why loading libXt before libXm causes a crash is unknown, and the only thing AWT can do is to print a warning or throw an exception. So I'm closing this bug as not reproducible.
Posted Date : 2005-12-30 11:58:51.0

I wonder if this is not somehow related to bug 4436372.  

I also repeated this bug in 1.4.0

I'm totally confused by this bug report (which I originally
submitted).  Why is there a second bug tagged onto the end
of the description field?  This second issue, from my
perspective, has nothing to do with my bug, and wasn't
submitted by me.

Secondly, the comments talk about motif shared library being
the problem, but my system doesn't even have motif on it! 
There is no libXm.so to load or pre-load.  

Please comment here or send me an e-mail explaining these
two anomolies.

Thank you.
  Nathan

Sun privately responded to my last comment with some
information that ALMOST gave us a workaround.  Since it
might help others, I figured I'd post my experience here.  

The problem is that awt is statically linked against motif.
 Knowing this I thought that perhaps preloading motif BEFORE
libXt was loaded might fix my problem.  In fact it does fix
the problem!  Unfortunately for us, it ends up breaking
other parts of our application (I guess because Motif has
made changes to libXt).  We may end up having to wait for
Sun to remove dependencies on Motif anyhow.

Was this fixed in 1.5 beta ?

I'm running into the same problem on solaris with java
1.4.0-b92.  

I've tried setting LD_PRELOAD to reference libawt (which
worked solved the problem on linux) but I still get the same
error about libXt loaded before libXm on solaris.

Is there any advice for getting around this problem on
solaris?  

I've tried adding libXm to the LD_PRELOAD too.  But that
produces a different crash when I try to interact with the GUI:

Function=XmFontListNextEntry+0x28
Library=/usr/dt/lib/libXm.so

Current Java thread:
        at
sun.awt.motif.X11InputMethod.createXICNative(Native Method)
        at
sun.awt.motif.X11InputMethod.activate(X11InputMethod.java:263)
        - locked <d4cd76f8> (a sun.awt.motif.X11InputMethod)
        at
sun.awt.im.InputContext.activateInputMethod(InputContext.java:339)

Any suggestions?

Thanks,

Ben