JDK-6599351 : javaws only runs in the left-hand screen on snv_71
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: solaris,solaris_11,5.0u12,6,6u1,6u4
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux,solaris_nevada
  • CPU: generic,x86,sparc
  • Submitted: 2007-08-30
  • Updated: 2011-01-19
  • Resolved: 2008-05-13
Related Reports
Duplicate :  
Relates :  
Description
javaws in snv_71 is apparently left-handed.

The following issue described on the Nevada users group also describes my symptoms perfectly.  It is 100% reproducible,

Since upgrading from snv_69 to snv_71 I can no longer display SunTea or Bugster on my right hand monitor (I'm not using Xinerama). Starting bugster generates the following stack:

flange> bugster
flange> Exception in thread "main" java.lang.ExceptionInInitializerError
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:164)
at java.awt.Toolkit$2.run(Toolkit.java:821)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:804)
at com.sun.javaws.Main.main(Main.java:76)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
at sun.awt.X11GraphicsEnvironment.getDefaultScreenDevice(X11GraphicsEnvironment.java:178)
at sun.awt.motif.MToolkit.<clinit>(MToolkit.java:93)
... 6 more

Running javaws -viewer generates a similar stack.

I have no problem displaying these two apps on my left hand monitor.

flange> java -version
java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Server VM (build 1.6.0_01-b06, mixed mode

I've tried using the previous version of Java and I get the same result.

My system is a twin Opteron box with two SUN GDM-5410 monitors. Running scanpci tells me I have the following graphics card:

pci bus 0x0003 cardnum 0x03 function 0x00: vendor 0x10de device 0x032a
 nVidia Corporation NV34GL [Quadro NVS 280 PCI]
this bug also seems to affect other applications like vncviewer in snv_74.
I have the same problem on a dual-head x86 system. The bug is always reproducible.
I don't use Cinerama, just 2 heads with two screens.

The stack trace:

$ javaws https://bugster.sfbay.sun.com/bugster.jnlp
543 aldan:/usr/lib$ Exception in thread "main" java.lang.ExceptionInInitializerError
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:169)
        at java.awt.Toolkit$2.run(Toolkit.java:836)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:828)
        at com.sun.javaws.Main.main(Main.java:96)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
        at sun.awt.X11GraphicsEnvironment.getDefaultScreenDevice(X11GraphicsEnvironment.java:218)
        at sun.awt.X11.XToolkit.<clinit>(XToolkit.java:93)
        ... 6 more

Comments
WORK AROUND The following change works for me: - save a backup copy of /usr/openwin/lib/libXext.so.0 - edit (in hex) /usr/openwin/lib/libXext.so.0 - find the string "XINERAMA" - change the X to a Z
03-12-2007

EVALUATION This email and bug could offer some explanation as to why XINERAMA extension is present: http://mail.openjdk.java.net/pipermail/awt-dev/2007-November/000109.html https://bugs.launchpad.net/ubuntu/+source/sun-java6/+bug/154613
01-12-2007

EVALUATION I was able to do some debugging (thanks to all those who offered their systems). Note that you do not need to setup xinerama in order to reproduce this, a multi-screen system would do fine. The problem boils down to the way we check if Xinerama is active. On solaris we rely on checking if the extension is present, and then on XineramaGetInfo() function from libXext.so: (see j2se/src/solaris/native/sun/awt/awt_GraphicsEnv.c) gotXinExt = XQueryExtension(awt_display, XinExtName, &major_opcode, &first_event, &first_error); if (gotXinExt) { if ((*XineramaSolarisFunc)(awt_display, 0, &fbrects[0], &fbhints[0], &locNumScr) != 0) { DTRACE_PRINTLN("Enabling Xinerama support"); usingXinerama = True; (where XineramaSolarisFunc is dlsym-ed XineramaGetInfo) Previously on solaris (with Xsun X server) the XINERAMA extension would only be present when xinerama was active so we would never even get to call XineramaGetInfo. With Xorg it appears that the extension is present even when it is not active, so we proceed to calling libXext's XineramaGetInfo() which for some reason doesn't return an error but reports success and that there is a single screen: locNumScr is set to 1. (this may actually be an Xorg bug, although there may be a requirement to check if xinerama is active first - but still, the function should have failed when xinerama is not active). On this particular system I ran my test on there are two screens, and xinerama is not enabled, but the extension is present. So if the default screen is set to be screen 1: DISPLAY=:0.1 our code assumes that xinerama is enabled, and the number of screens is 1 (as returned by XineramaGetInfo(). However, the rest of X calls contradict this, for example, DefaultScreen(dpy) returns 1, XScreenCount returns 2, etc. Now you can see where that would be a problem. In particular, when we try to get the default GraphicsDevice we get the default screen number by doing downcall to DefaultScreen(dpy) (which returns 1) and attempt to access screens[1], but since we think that there's only one screen we get an ArrayOutOfBoundsException. So I think we should change the way we detect Xinerama. We may also investigate if the behavior of XineramaGetInfo has changed recently and if the change was incompatible. Reassigning to AWT (screen initialization and xinerama detection belongs to AWT).
30-11-2007

EVALUATION And I don't think this is a Java 6 problem only either. I can get a similar stack trace running any of the 1.5 demos like jfc/Notepad.
30-11-2007

EVALUATION Note that I don't have xinerama. I have 2 separate displays that I can't drag things across.
30-11-2007

EVALUATION It is likely that our way of detecting xinerama on Solaris fails so we think that there's more than one screen or something. It is probably related to the recent changes to solaris' x server (XSun -> Xorg) Could someone on the interest list who has a system on which the problem is reproducible please contact me (it will take a long time for us to setup one).
30-11-2007

EVALUATION it looks like 2D was unable to correctly initialize array of screen devices and can not get elemt with index 1. Transvering to 2D team for further investigation.
31-08-2007

EVALUATION one strange thing I see is that AWT is trying to load MToolkit which is not a default toolkit in 6.0 and later. Do you have MToolkit environment variable set? If so, could you try to unset it and retest. Another question is if the problem is reproducible with java applications such as SwingSet (its location is <java home>/demo/jfc/SwingSet) To run it exec java -jar SwingSet.jar Or, if you do use older (1.5) java, please, check the behavior with 1.6 Also it would be nice to verify if the problem is reproducible with java applications such as SwingSet (its location is <java home>/demo/jfc/SwingSet) To run it exec java -jar SwingSet.jar I'm marking the CR as incomplete for now (we obviously need more infor ;)
31-08-2007