JDK-6513886 : jEdit splash throws NPE with Java 1.6 on NoMachine NX display
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: linux
  • CPU: x86
  • Submitted: 2007-01-17
  • Updated: 2021-07-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-6570758 - REGRESSION: 1.6 throws InternalError when trying to exit full screen exclusive mode, Linux
Description
FULL PRODUCT VERSION :
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)


ADDITIONAL OS VERSION INFORMATION :
Linux crash.domain.tld 2.4.21-47.0.1.ELsmp #1 SMP Thu Oct 19 11:33:45 EDT 2006 i686 i686 i386 GNU/Linux

EXTRA RELEVANT SYSTEM CONFIGURATION :
The problem shows up with NoMachine NX and it also seems to happen with Cygwin's X Server.

A DESCRIPTION OF THE PROBLEM :
Try starting jEdit-4.3pre8 using Java 6 (jre 1.6.0) on NX, it will crash when trying to display the splash screen. It works well with other X servers and also Xnest, but it also works well with jre 1.5 on NX. Trying to find out where exactly it fails, it seems that it's how the RANDR extension is implemented in NX and Java 6. Renaming /usr/X11R6/lib/libXrandr.so.2.0 before starting jEdit makes it work. I'm aware that this could also be a bug in NX, but I got reports now that it also happens with Cygwin's X Server.
There is some more info here
https://sourceforge.net/tracker/index.php?func=detail&aid=1628432&group_id=588&atid=100588

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
nxagent -ac :1 &
export DISPLAY=:1
jedit

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
jEdit should show it's splash screen and then start up.
ACTUAL -
jEdit doesn't start.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
[error] main: Exception in thread "main"
[error] main: java.lang.NullPointerException
[error] main: at org.gjt.sp.jedit.gui.SplashScreen.<init>(SplashScreen.java:59)
[error] main: at
org.gjt.sp.jedit.GUIUtilities.showSplashScreen(GUIUtilities.java:1622)
[error] main: at org.gjt.sp.jedit.jEdit.main(jEdit.java:309)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
57:                GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
58:                GraphicsDevice[] gs = ge.getScreenDevices();
59:                int height = gs[0].getDisplayMode().getHeight();
60:                int width = gs[0].getDisplayMode().getWidth();

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

CUSTOMER SUBMITTED WORKAROUND :
Starting jEdit without splash makes it work:
touch .jedit/nosplash
jedit
Comments
EVALUATION After some help from the submitters on this page: https://sourceforge.net/tracker/index.php?func=detail&aid=1628432&group_id=588&atid=100588 it was determined that apparently in some configurations randr returns 0 for refresh rate: $ xrandr SZ: Pixels Physical Refresh 0 1024 x 768 ( 347mm x 260mm ) 1 160 x 120 ( 54mm x 41mm ) 2 320 x 240 ( 108mm x 81mm ) 3 640 x 480 ( 217mm x 163mm ) 4 800 x 600 ( 271mm x 203mm ) 5 1600 x 1200 ( 542mm x 406mm ) *6 1200 x 900 ( 406mm x 305mm ) Current rotation - normal Current reflection - none Rotations possible - normal Reflections possible - none Unfortunately we treat such display modes as invalid and return null from GraphicsDevice.getDisplayMode(), causing the NPE in the caller. We should be handling this better. Here's a simple test app that could be used for testing this functionality: import java.awt.*; public class GETest { public static void main(String... args) { GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment(); System.err.println("ge="+ge); GraphicsDevice gds[] = ge.getScreenDevices(); for (GraphicsDevice gd : gds) { System.err.println("GraphicsDevice: "+gd); System.err.println("FS supported?"+gd.isFullScreenSupported()); if (gd.getDisplayMode() != null) { DisplayMode dm = gd.getDisplayMode(); System.err.printf("default DM(%dx%dx%d@%d)\n", dm.getWidth(), dm.getHeight(), dm.getBitDepth(), dm.getRefreshRate()); } else { System.err.println("ERROR: default DM is null!"); } DisplayMode dms[] = gd.getDisplayModes(); System.err.println("Display modes:"); for (DisplayMode dm : dms) { System.err.printf(" dm(%dx%dx%d@%d)\n", dm.getWidth(), dm.getHeight(), dm.getBitDepth(), dm.getRefreshRate()); } } } } Here's the output on my configuration (cygwin X server): ge=sun.awt.X11GraphicsEnvironment@3901c6 GraphicsDevice: X11GraphicsDevice[screen=0] FS supported? false default DM(1280x1024x-1@0) Display modes: dm(1280x1024x-1@0) Note that on my system the bug doesn't manifest because isFullScreenSupported() returns false (randr wasn't found/configured correctly, even though RANDR extension is reported as supported by xdpyinfo). I'm reassigning this bug to the engineer responsible for FS mode on unix platforms.
17-01-2007
EVALUATION So far I haven't been able to reproduce the null pointer exception described (with either SwingSet2 or jedit). However, I don't have the exact system either. I used XP with Cygwin X server. With just plain remote X to the cygwin X server everything works fine on jdk6 (I tried SwingSet which uses the jdk6 splash screen functionality, and jedit 4.3pre8). However, there appears to be a regression in jdk7 (b05), I get the following exception when displaying remotely to cygwin X server: Exception in thread "main" java.lang.NullPointerException at sun.awt.X11.XToolkit.getScreenInsets(XToolkit.java:712) at java.awt.Window.init(Window.java:369) at java.awt.Window.<init>(Window.java:320) at java.awt.Frame.<init>(Frame.java:428) at java.awt.Frame.<init>(Frame.java:386) at javax.swing.JFrame.<init>(JFrame.java:187) at SwingSet2.createFrame(SwingSet2.java:859) at SwingSet2.<init>(SwingSet2.java:199) at SwingSet2.main(SwingSet2.java:230) This is apparently a known problem, fix will be integrated soon. However, with jdk6 I've ran into a crash when displaying remotely to a cygwin server through ssh (one of the scenarios mentioned on this page (this is running SwingSet2): https://sourceforge.net/tracker/index.php?func=detail&aid=1628432&group_id=588&atid=100588 ) Stack: [0x404d4000,0x406d3000), sp=0x406d2a1c, free space=2042k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libc.so.6+0x816cc] C [libc.so.6+0x81424] __libc_free+0xb4 C [libsplashscreen.so+0xd22f] SplashCleanupPlatform+0x6f C [libsplashscreen.so+0xadca] SplashCleanup+0x2a C [libsplashscreen.so+0xaeb2] SplashDone+0x22 C [libsplashscreen.so+0xdabc] SplashScreenThread+0xac C [libpthread.so.0+0x6c6f] (hs log file is attached) I could not reproduce the crash with jdk7 because of the aforementioned exception (it apparently happens earlier than the crash). But since jEdit doesn't use the built-in jdk6 splash functionality, this crash is likely unrelated, so I'll file a separate bug. JEdit 4.3pre8 worked fine for me both displaying to cygwin X server and through ssh tunnel. At this point, I need more information from the submitter: - output of xdpyinfo - does the problem manifest with any other applications - does it manifest if org.gjt.sp.jedit.gui.SplashScreen is used standalone (looks like a simple test app with this class only should be easy to try)
17-01-2007