United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4636548 Crash of virtual machine 1.4b92 when special screensaver on Win2K is activated.
JDK-4636548 : Crash of virtual machine 1.4b92 when special screensaver on Win2K is activated.

Details
Type:
Bug
Submit Date:
2002-02-12
Status:
Closed
Updated Date:
2002-09-03
Project Name:
JDK
Resolved Date:
2002-06-27
Component:
client-libs
OS:
windows_nt,windows_98,windows_xp,windows_2000
Sub-Component:
2d
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.0
Fixed Versions:
1.4.1 (rc)

Related Reports
Duplicate:
Duplicate:
Relates:

Sub Tasks

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
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;
      }
                                     
2004-06-11
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
hopper-rc

FIXED IN:
hopper-rc

INTEGRATED IN:
hopper-rc

VERIFIED IN:
hopper-rc


                                     
2004-06-14
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
                                     
2002-09-03



Hardware and Software, Engineered to Work Together