United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4738111 : java crashes or hangs when display mode changes on Matrox g400 (Windows only)

Details
Type:
Bug
Submit Date:
2002-08-28
Status:
Resolved
Updated Date:
2003-01-13
Project Name:
JDK
Resolved Date:
2003-01-13
Component:
client-libs
OS:
windows_nt,windows_2000
Sub-Component:
2d
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.1,1.4.2
Fixed Versions:
1.4.1_02 (02)

Related Reports
Backport:
Duplicate:
Duplicate:
Relates:
Relates:

Sub Tasks

Description
With my desktop system (dual PIII-800, Matrox g400 dual head (only one
display set)), when I install an older driver (version 5.0.2195.1020, from 
the file w2k501.exe attached to this bug report, downloaded from matrox.com),
any java app crashes when I run another directX app fullscreen.  For example,
when I run the matrix-3d screen saver (also attached to this bug report).

To reproduce:
- install this driver version
- run notepad (java -jar Notepad.jar in demo/jfc/Notepad)
- run the screen saver (or another DirectX fullscreen app)
- note that Notepad quietly exited with no stack trace

This problem was first reported by another user with a similar setup, using
driver version 5.0.2195.1030.

-------------------------
I am able to reproduce similar problems with Java apps alone.  Run
DisplayModeTest, choose another display mode, and click "Set Display".
The app will quietly exit at this point.  A similar effect is seen in any
fullscreen Java app that attempts to set the display mode.

###@###.### 2002-11-07

See the description to bug 4798194, which I just closed as a duplicate of this
bug.  Older matrox drivers cause Java to exit, but newer Matrox drivers have a different problem: Java simply hangs.  For example, run the SetDM app attached to this bug report.  On older drivers, the app simply exits, on newer drivers, the app hangs in fullscreen mode and you have to run the task manager to exit the app (alt-tab does not function correctly).

###@###.### 2003-01-06

                                    

Comments
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
1.4.1_02
mantis-beta

FIXED IN:
1.4.1_02
mantis-beta

INTEGRATED IN:
1.4.1_02
mantis-b13
mantis-beta


                                     
2004-06-14
WORK AROUND

Don't run another DirectX fullscreen app while java is running.  Note that the
usual noddraw flag does nothing to fix this problem.

Upgrade drivers to recent version.
                                     
2004-06-11
EVALUATION

Note that although the -Dnoddraw and -Dd3d flags do not affect this problem,
the problem does not exist on pre-1.4 versions of the jdk.
###@###.### 2002-08-29

I verified with the submitter that the problem comes from an older Matrox
driver; when he upgraded to a more recent driver the problem went away.  Similarly, when I downgraded to an older version (close to the version used by the submitter), I was able to reproduce the problem.

So the ultimate fix here is to upgrade your video drivers to a more recent version; you can get newer drivers from www.matrox.com.  However, we should
still figure out what we are doing that is triggering this problem in the
driver.

When tracing the problem in standalone Java apps (see the updated Description),
I can see that the SetDisplayMode call works fine.  Later, the primary surface
is recreated without a problem as well.  Then the app exits sometime after that.
More investigation necessary.

###@###.### 2002-11-07

As documented in bug 4798164, the fix is simple: don't call getDefaultPixID(screen) in Win32GraphicsDevice during the displayChanged() method.  The call is unnecessary and causes a call to ChoosePixelFormat, which is an OpenGL call which triggers the driver exit/hang bugs that we are seeing.

###@###.### 2003-01-06

The root of the problem (the call to an OpenGL-related function) points out
why this bug cropped up with DirectX screen savers and not the default
OpenGL screen savers.  The problem (with the matrox driver) was not in
calling the pixel format function at all, but calling it while some
DirectX process (perhaps even our own) had fullscreen exclusive ownership
of the display.  If an OpenGL application owns the display (as it does
with the GL screen savers), there is no conflict.  But if DirectX owns
the display, the call to ChoosePixelFormat either hangs or fails outright.

###@###.### 2003-01-06
                                     
2003-01-06



Hardware and Software, Engineered to Work Together