JDK-4636548 : Crash of virtual machine 1.4b92 when special screensaver on Win2K is activated.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS:
    windows_98,windows_nt,windows_2000,windows_xp windows_98,windows_nt,windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2002-02-12
  • Updated: 2002-09-03
  • Resolved: 2002-06-27
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
1.4.1 rcFixed
Related Reports
Duplicate :  
JDK-4702062 - Bad color/sizing of graphics objects after other fullscreen app run (win32 only)
Duplicate :  
JDK-4639735 - FullScreen: getDisplayMode() fails, and "Could not get display mode".
Relates :  
JDK-4738111 - java crashes or hangs when display mode changes on Matrox g400 (Windows only)
Description
Environment:
============
Forte for Java 4.0, CE Build #020211_1 with JDK 1.4.0 build #92 on Windows 2000

Description:
============
I have discovered reproducable crash of virtual machine that happens on Windows 2000 box when I leave my workstation for a while and the attached screensaver is activated. When I then press SPACE key that stops this screensaver virtual machine does not survive the switch of display modes. I am attaching both the screensaver and generated log file. Please forgive me if I assigned it to wrong subcategory. I hope also P2/S1 is adequate since I have lost all of my unsaved files.

Steps to reproduce:
===================
1. Instal JDK 1.4.0 build #92 on some Windows 2000 machine.
2. Instal Forte for Java 4.0, CE build #020211_1 and launch it using this JDK.
3. Execute attached Matrix screensaver.
4. After you were watching it for a while press SPACE key to stop it.
5. When Windows 2000 comes back there will be no Forte running.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: hopper-rc FIXED IN: hopper-rc INTEGRATED IN: hopper-rc VERIFIED IN: hopper-rc
14-06-2004
SUGGESTED FIX ------- ddrawUtils.cpp ------- *** /tmp/sccs.ppaq4N Mon Jun 10 15:18:47 2002 --- ddrawUtils.cpp Mon Jun 10 15:13:08 2002 *************** *** 499,505 **** if (tmpDdInstance->hwndFullScreen == NULL) { AwtWin32GraphicsDevice::DisableOffscreenAccelerationForDevice( tmpDdInstance->hMonitor); ! ReleaseDDInstance(tmpDdInstance); } return FALSE; } --- 499,507 ---- if (tmpDdInstance->hwndFullScreen == NULL) { AwtWin32GraphicsDevice::DisableOffscreenAccelerationForDevice( tmpDdInstance->hMonitor); ! // 4636548: Do not release the DDInstance because the loss of ! // the primary surface may be only temporary due to another app ! // entering fullscreen mode (such as a screensaver). } return FALSE; }
11-06-2004
EVALUATION Commit to fix in mantis (crash). ###@###.### 2002-02-12 The attached screensaver is a binary only file. In order to debug this problem, we need the source code. ###@###.### 2002-05-02 I believe the author is ###@###.###. Write him, maybe he will agree to give you the sources. Company's web page is http://3dscr.com. ###@###.### 2002-05-03 I discovered several easy ways to reproduce this problem. Run a simple java application (such as FullScreen/CapabilitiesTest) using 1.4 or later and then launch a second fullscreen app. The first app will crash. This is a nasty bug that will crash *any* java app simply whenever a Windows 2000 app is launched (such as a screensaver). I'm raising the priority and have updated the suggested fix. ###@###.### 2002-06-10 Handing over to Java2D. ###@###.### 2002-06-12 Looks like the failure to create the primary comes from certain situations in which we receive a ddraw error. For example, when there is another DirectX app running in fullscreen mode, then we tend to get the error DDERR_NOEXCLUSIVEMODE, which indicates that we cannot create a primary surface when another application has exclusive mode access to the screen. Interestingly, this problem seems specific to DirectX apps; presumably OpenGL apps have another mechanism for accessing fullscreen that does not conflict with our direct draw code. The suggested fix is probably correct, although we may want to go farther. At the very least, we do not want to delete one of the ddInstance[] devices just because we failed to allocate a ddraw primary surface for that device at a particular time; deleting the ddInstance object is a one-way operation in the current code and we will not be able to accelerate future operations during this runtime. Of course, this operation also causes a later crash, but even were we to fix the crash bug we still do not want to disable acceleration simply because we were running in the background while a fullscreen app took over the machine. We also want to make sure we do not disable acceleration for offscreen surfaces, which is something else that happens in the current code upon primary creation failure. Although the effects of this bug are severe (crashed application), the fact that it takes outside stimulus to cause the crash (DirectX app running fullscreen) should be taken into account. I'm downgrading this to a P2. ###@###.### 2002-06-13 Note that the fix for the crash shows up color/sizing problems in the application (See bug 4702062 for more information, but I am closing that bug as a duplicate of this one since they are all caused by the same base problem). ###@###.### 2002-06-18 I don't want to disappoint you guys, but there is no change of this ugly behaviour in the latest RC build of Merlin #16. Is it supposed to be fixed there ? ###@###.### 2002-07-08 The crash reported in this last comment is not related to the bug fix; I was only able to reproduce this last crash by running on the exact same video card (Matrox G400 dual head) with the same (old) driver version; running on the latest drivers for that equipment appears to fix the problem. So this last report appears to be a driver version bug that is fixed by upgrading the driver, not by anything related to Java. ###@###.### 2002-08-19 I have opened up a new bug against this old-driver problem: 4738111. In general, we require use of the latest display drivers and it is not possible to work around all display driver bugs. However, we should at least figure out why we are crashing and work around it if at all possible. ###@###.### 2002-08-30 I am very happy to say, that the crash does not occur any more since I upgraded the driver for my Matrox G400 DualHead card. Thank you so much Chet for your patience. Confirming as fixed in build #19 of Hopper. ###@###.### 2002-09-03
03-09-2002