When a machine is running as a connected NetSupport client, it is possible
to hang during any graphical Java app startup in Win32GraphicsEnv.initDisplay().
In particular, this happens when the client is set to 32 bpp display depth.

To reproduce this bug, install a demo of NetSupport manager 
(www.netsupport-inc.com) on two machines: one will be the client (where the
problem will appear) and one will be the controller which connects to the
client.  Using the client configurator, name the client machine.  Using the
controller, connect to that client.  (Be sure to run in 32bpp display
depth; and don't switch display modes while connected in NetSupport; this
crashed my system consistently (nothing to do with Java on this one...)).

Now, on the client (either locally or remotely), run a Java app and note that
it hangs before displaying anything.  If you type ctrl-Break in the console,
you will probably see one of the threads hung in Win32GraphicsEnv.initDisplay().

This bug should only occur in 32 bpp screen depth.  If users run in any
other depth (8, 15, 16, 24), things should work fine.
 xxxxx@xxxxx  2002-05-16

This hang is due to an infinite loop in AwtWin32GraphicsDevice::Initialize().

NetSupport does something very funky when it connects to the client; it fakes
out the OS to tell it that there are two monitors.  When a Java app runs, we
set up color models for each device/monitor on the system.  For this second
NetSupport monitor, we go through the same Initialize() function that we 
always do, only we get an error this time when calling GetDIBits().

We assert on this error in debug mode, but otherwise do nothing about it.
In particular, we assume that the values set in this function are valid and
we continue on about our business in that function.  The problem is that we
spin in loops around the red/green/blue values that were supposed to be set
in that function, waiting for a certain condition to be true (we shift
the values until they are non-null).  But since the function error'd out, the
values are not set, and we could end up spinning in a loop forever
(basically, waiting for a value of "0" to become non-null).

It's not clear why GetDIBits() is failing in this particular situation, although
it seems like a bug in the NetSupport code; we are passing in valid values
to the function and they work on every other platform.  But for some 
reason, the NetSupport code does not like to be called with the biCompression
field in the BITMAPINFOHEADER structure set to BI_BITFIELDS when the display
depth is 32 bpp.  This is a valid value to pass, but it just doesn't work 
in this situation.

There are 2 fixes that should be applied to our code to fix this and
future problems:
	- trap the error and do something intelligent about it.  We could
	and should at least set some default values for the rgb masks and 
	exit the function cleanly without spinning in these loops.
	- Move the 32 bpp case down to the 24 bpp case; let them both use
	BI_RGB instead of 32 bpp using BI_BITFIELDS.  Both of these are
	acceptable values for 32 bpp; the BI_BITFIELDS is a little more 
	general, but the masks for 32 bpp are pre-ordained anyway, so I don't
	know why we need that flexibility in our code.

Of course it would be nice if NetSupport fixed the bug in their app as well,
but that does not fix the whole problem and we cannot count on that
for all of our customers.

 xxxxx@xxxxx  2002-05-14

I will leave the code basically the way it is (leaving the 32 bpp case
as a BI_BITFIELDS case), and just handle the error in GetDIBits by
hardcoding the results.

By leaving the code basically as is, we run less risk of breaking something
else.  For example, the SGI NT machines use a bizarre (or at least uncommon)
framebuffer format of RGBX.  If I hardcode 32 bpp bitmasks for colormap
creation, will this cause bad color effects on such framebuffers?  By
simply handling the error instead, I will essentially only change the
functionality on cases which, by definition, do not currently work, thus
leaving existing/working platforms (such as the SGI machine) alone.

 xxxxx@xxxxx  2002-05-16

Note to JDC submitters: This bug is fixed in a release (mantis, or 1.4.2)
that is not yet released.  Thus you will not see the fix until you can
download the release that has the fix.  There should be a beta available for
1.4.2 soon; when it is available, try that out and your problems should 
go away...

 xxxxx@xxxxx  2003-02-14

NetSupport has another problem in conjunction with Java, it 
doesn't let Ctrl-BREAK through, so it can be hard to get the 
JVM thread dump unless you sit at the machine locally.

This bug IS NOT FIXED!  initDisplay() hangs event when I do 
not run NetSupport!!!  It is present in ALL currently released 
versions of Java 1.4.  It never happened in Java 1.3!  It even 
does not work when I reboot the machine and have NOTHING 
else running.  I do NOT know any workarounds.  This is a very 
serious showstopper for me right know.  Please let me know 
when you are going to fix it.

Thank you
Vladislav Tolmach
Highbridge Capital Management
9 West 57th Street
27th Floor
New York, NY 10019
(212) 287-4935

We are seeing this problem as well.  Mostly with folks that 
Have ATI Rage Mobility graphics cards (in IBM thinkpads, no 
small market here!)

It is so bad that even surfing to the link to download the 
V1.4.1 pluggin (http://dlres.java.sun.com/PluginBrowserCheck?
pass=http://java.sun.com/getjava/installer.html&fail=http://
java.sun.com/getjava/others.html) peg's the CPU with 
internet explorer's AWT thread hung in this mode).

Here's the stack trace:
"main" prio=5 tid=0x002F8C48 nid=0x5e0 runnable 
[126000..12705c]
        at sun.awt.Win32GraphicsEnvironment.initDisplay(Native 
Method)
        at sun.awt.Win32GraphicsEnvironment.initDisplayWrapper
(Unknown Source)
        at sun.awt.Win32GraphicsEnvironment.<clinit>(Unknown 
Source)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Unknown Source)
        at 
java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment
(Unknown Sour
ce)
        - locked <0AA2EBC8> (a java.lang.Class)
        at java.awt.Window.init(Unknown Source)
        at java.awt.Window.<init>(Unknown Source)
        at java.awt.Frame.<init>(Unknown Source)
        at java.awt.Frame.<init>(Unknown Source)
        at sun.plugin.AppletViewer.<clinit>(Unknown Source)
        at sun.plugin.JavaRunTime.initEnvironment(Unknown 
Source)

Agree. Not fixed. Even if I change my pixel depth it still 
persists.

Please, pay attention to  the 'Release Fixed' field in the bugreport.

This bug has been fixed in 1.4.2 (aka mantis), which hasn't been released yet. Beta is due out in March.

Dmitri Trembovetski
Java2D Team

It also heppend in Unix Solaris System. I Wrote a program 
running in deamon, but it always shows me some following 
message:

Exception in thread "main" java.lang.InternalError: Can't 
connect to X11 window
server using ':0.0' as the value of the DISPLAY variable.
at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
at sun.awt.X11GraphicsEnvironment.<clinit>(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment
(Unknown Source)
at java.awt.image.BufferedImage.createGraphics(Unknown 
Source)

Did the new java-runtime-enviroment fix this error?

Restart your machine after changing the pixel depth. It 
should work; worked for me!