JDK-4738111 : java crashes or hangs when display mode changes on Matrox g400 (Windows only)
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.1,1.4.2
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_nt,windows_2000
  • CPU: x86
  • Submitted: 2002-08-28
  • Updated: 2003-01-13
  • Resolved: 2003-01-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.
1.4.1_02 02Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
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

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

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.

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