JDK-6322854 : fail when trying to run any java app or applet under e17
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: linux
  • CPU: x86
  • Submitted: 2005-09-12
  • Updated: 2011-04-28
Description
FULL PRODUCT VERSION :
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)

and

java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_04-b05, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Linux linux 2.6.12.5 #3 Sat Aug 20 10:27:33 PDT 2005 x86_64 unknown unknown GNU/Linux

(I reported as a general Linux (not only 64bit) because e17 developers did apply a patch to "emulate" e16 to make jvm work there)

EXTRA RELEVANT SYSTEM CONFIGURATION :
tested for applets, java awt apps, java Swing apps and java console apps with server and client configuration

e17 was compilled as a 64bit app and both modes (64bit and 32bit) jvm were tested

A DESCRIPTION OF THE PROBLEM :
when trying to run any java app using JVM 1.4 or 1.5 it fails with the following error:

Atom was 0
java.lang.ExceptionInInitializerError
        at org.netbeans.core.NonGui.getUserDir(NonGui.java:118)
        at org.netbeans.core.NonGui.getLogDir(NonGui.java:147)
        at org.netbeans.core.CLIOptions.initialize(CLIOptions.java:192)
        at org.netbeans.core.Main.start(Main.java:304)
        at org.netbeans.core.TopThreadGroup.run(TopThreadGroup.java:90)
        at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.NullPointerException: Failed to retrieve atom name.
        at sun.awt.X11.XlibWrapper.XGetAtomName(Native Method)
        at sun.awt.X11.XAtom.<init>(XAtom.java:219)
        at sun.awt.X11.XAtom.get(XAtom.java:146)
        at sun.awt.X11.XAtom.getAtomListProperty(XAtom.java:630)
        at sun.awt.X11.XAtom.getAtomListPropertyList(XAtom.java:644)
        at sun.awt.X11.XProtocol.checkProtocol(XProtocol.java:37)
        at sun.awt.X11.XNETProtocol.doStateProtocol(XNETProtocol.java:273)
        at sun.awt.X11.XWM.initializeProtocols(XWM.java:1178)
        at sun.awt.X11.XWM.<init>(XWM.java:113)
        at sun.awt.X11.XWM.getWM(XWM.java:559)
        at sun.awt.X11.XWM.init(XWM.java:1169)
        at sun.awt.X11.XToolkit.<init>(XToolkit.java:320)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
        at java.lang.Class.newInstance0(Class.java:350)
        at java.lang.Class.newInstance(Class.java:303)
        at java.awt.Toolkit$2.run(Toolkit.java:833)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:804)
        at javax.swing.UIManager.initialize(UIManager.java:1262)
        at javax.swing.UIManager.maybeInitialize(UIManager.java:1245)
        at javax.swing.UIManager.getDefaults(UIManager.java:556)
        at javax.swing.filechooser.FileSystemView.getFileSystemView(FileSystemView.java:63)
        at org.openide.filesystems.FileUtil.<clinit>(FileUtil.java:49)
        ... 6 more
Atom was 0

I have researched at the source code and i find a little silly the way the JVM try to guess what wm is running, because you are not thinking in another window managers; even some bad positioning happen when using kde in two different pc's; i would recommend to see for more general options inside Xserver and have a default generic config for any other wm (in case it is not registered or a nullpointerException is returned (like in this case)

the window manager should not be relevant when trying to run a Java Console App(some apps of this kind will not run and another ones would run perfectly).


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
just try to run any java app or applet you want under e17 in a Linux amd64 system.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
run the app (any)
ACTUAL -
Atom was 0
java.lang.ExceptionInInitializerError
        at org.netbeans.core.NonGui.getUserDir(NonGui.java:118)
        at org.netbeans.core.NonGui.getLogDir(NonGui.java:147)
        at org.netbeans.core.CLIOptions.initialize(CLIOptions.java:192)
        at org.netbeans.core.Main.start(Main.java:304)
        at org.netbeans.core.TopThreadGroup.run(TopThreadGroup.java:90)
        at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.NullPointerException: Failed to retrieve atom name.
        at sun.awt.X11.XlibWrapper.XGetAtomName(Native Method)
        at sun.awt.X11.XAtom.<init>(XAtom.java:219)
        at sun.awt.X11.XAtom.get(XAtom.java:146)
        at sun.awt.X11.XAtom.getAtomListProperty(XAtom.java:630)
        at sun.awt.X11.XAtom.getAtomListPropertyList(XAtom.java:644)
        at sun.awt.X11.XProtocol.checkProtocol(XProtocol.java:37)
        at sun.awt.X11.XNETProtocol.doStateProtocol(XNETProtocol.java:273)
        at sun.awt.X11.XWM.initializeProtocols(XWM.java:1178)
        at sun.awt.X11.XWM.<init>(XWM.java:113)
        at sun.awt.X11.XWM.getWM(XWM.java:559)
        at sun.awt.X11.XWM.init(XWM.java:1169)
        at sun.awt.X11.XToolkit.<init>(XToolkit.java:320)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
        at java.lang.Class.newInstance0(Class.java:350)
        at java.lang.Class.newInstance(Class.java:303)
        at java.awt.Toolkit$2.run(Toolkit.java:833)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:804)
        at javax.swing.UIManager.initialize(UIManager.java:1262)
        at javax.swing.UIManager.maybeInitialize(UIManager.java:1245)
        at javax.swing.UIManager.getDefaults(UIManager.java:556)
        at javax.swing.filechooser.FileSystemView.getFileSystemView(FileSystemView.java:63)
        at org.openide.filesystems.FileUtil.<clinit>(FileUtil.java:49)
        ... 6 more
Atom was 0

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Atom was 0
java.lang.ExceptionInInitializerError
        at org.netbeans.core.NonGui.getUserDir(NonGui.java:118)
        at org.netbeans.core.NonGui.getLogDir(NonGui.java:147)
        at org.netbeans.core.CLIOptions.initialize(CLIOptions.java:192)
        at org.netbeans.core.Main.start(Main.java:304)
        at org.netbeans.core.TopThreadGroup.run(TopThreadGroup.java:90)
        at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.NullPointerException: Failed to retrieve atom name.
        at sun.awt.X11.XlibWrapper.XGetAtomName(Native Method)
        at sun.awt.X11.XAtom.<init>(XAtom.java:219)
        at sun.awt.X11.XAtom.get(XAtom.java:146)
        at sun.awt.X11.XAtom.getAtomListProperty(XAtom.java:630)
        at sun.awt.X11.XAtom.getAtomListPropertyList(XAtom.java:644)
        at sun.awt.X11.XProtocol.checkProtocol(XProtocol.java:37)
        at sun.awt.X11.XNETProtocol.doStateProtocol(XNETProtocol.java:273)
        at sun.awt.X11.XWM.initializeProtocols(XWM.java:1178)
        at sun.awt.X11.XWM.<init>(XWM.java:113)
        at sun.awt.X11.XWM.getWM(XWM.java:559)
        at sun.awt.X11.XWM.init(XWM.java:1169)
        at sun.awt.X11.XToolkit.<init>(XToolkit.java:320)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
        at java.lang.Class.newInstance0(Class.java:350)
        at java.lang.Class.newInstance(Class.java:303)
        at java.awt.Toolkit$2.run(Toolkit.java:833)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:804)
        at javax.swing.UIManager.initialize(UIManager.java:1262)
        at javax.swing.UIManager.maybeInitialize(UIManager.java:1245)
        at javax.swing.UIManager.getDefaults(UIManager.java:556)
        at javax.swing.filechooser.FileSystemView.getFileSystemView(FileSystemView.java:63)
        at org.openide.filesystems.FileUtil.<clinit>(FileUtil.java:49)
        ... 6 more
Atom was 0

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
 Frame blah = new Frame("blah");
---------- END SOURCE ----------
Comments
EVALUATION External developers confirm there is a bug in synergy when running in 64-bit mode. The patch can be found here: https://bugs.launchpad.net/ubuntu/+source/synergy/+bug/207057 Still, this problem was found while investigation for another NPE thrown from XClipboard.getContents(), so we should also check if the patch help with the original NPE from XNETProtocol.getState() or not.
04-08-2008
EVALUATION Some more technical details from Java's point of view. When user requests clipboard contents, AWT first requests a value of TARGETS atom for CLIPBOARD selection (I suspect the owner is some synergy server window). The code is in XSelection.getFormats(): XlibWrapper.XConvertSelection(XToolkit.getDisplay(), // X display connection getSelectionAtom().getAtom(), // CLIPBOARD atom XDataTransferer.TARGETS_ATOM.getAtom(), // TARGETS atom selectionPropertyAtom.getAtom(), // "XAWT-SELECTION" to fill XWindow.getXAWTRootWindow().getWindow(), // requestor window time); The call is successful, and the next thing is to get the value of "XAWT-SELECTION" and convert it to the list of atoms. Here is the list on my linux with synergy client running: 0x189, 0x18a, 0x18b, 0x194, 0xf4, 0x195, 0x196, 0x197, 0x1f, 0x0, 0x14aa1, 0xfffffffff9530698, 0xfffffffff9530698, 0x18a, 0x18b, 0x194, 0xf4, 0x195 Value 0x0 seems odd to me, as well as other repeating values. This only happens when Java and one of synergy clients are started from 64-bit linux, regardless of where synergy server is running.
29-07-2008
EVALUATION Using synergy, I was able to reproduce the problem in a mixed 32/64-bit environment: synergy server and one of the clients is running on my 32-bit windows box, while other client is running on 64-bit linux desktop.
29-07-2008
EVALUATION Users on this forum found that it's easy to reproduce using Synergy: http://forums.java.net/jive/thread.jspa?messageID=289889#289889
28-07-2008
EVALUATION The code from JDK1.5.0 is now changed and as correctly noticed by the submitter this problem shouldn't appear in JDK6.0. JDK5.0: .... synchronized (XToolkit.getAWTLock()) { this.name = XlibWrapper.XGetAtomName(display, atom); } .... Now if atom is null then register() routine will return silently. There is no other places with atomname usage.
28-09-2005
EVALUATION Please confirm that: - the problem happens with Java 1.4 - the problem happens with Java 1.6 - the problem happens on 32-bit Linux as well
13-09-2005