JDK-4754180 : blue-screen system crash on FullScreenTest when alt-tabbing
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.1_01
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2002-09-26
  • Updated: 2002-12-11
  • Resolved: 2002-11-16
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 Other
1.4.1_02 02Fixed 1.4.2Fixed
Description
First, uncomment the lines in FullScreenTest that cause the test to loop
on backBuffer.contentsLost().  Next, make sure that we are creating a 
new VolatileImage at the top of render() (this is how the test is written
now, but since this is so suboptimial, we should probably rewrite the test
te behave better eventually...).  Now, run the test, alt-tab out and 
back into it.  I can get my desktop system to blue-screen after just a couple of
alt-tabs out of and back into the app.

My system is a PIII-750, win2k, Radeon 7500, 1280x1024x32bpp, DirectX8,
driver ati2dvag.dll version 5.13.1.6043.

Updated the Synopsis field since this appears to be a general DirectX issue
that is reproducible on at least the Radeon and a GeForce2 card.

###@###.### 2002-10-28
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.1_02 mantis FIXED IN: 1.4.1_02 mantis INTEGRATED IN: 1.4.1_02 mantis
14-06-2004
WORK AROUND Run with -Dsun.java2d.d3d=false
11-06-2004
EVALUATION The root cause of this problem is in the DirectX runtime or the ATI driver. I have written a native app that exhibits the same behavior. The problem is that accessing d3d through a surface that was created prior to an alt-tab event causes the system crash in EndScene. There is no warning or error during the SetRenderTarget, BeginScene, or DrawPrimitive calls, so there is no way for us to detect a problem prior to crashing. It is possible for us to detect an alt-tab event, via the WM_ACTIVATEAPP message. however, the multithreaded nature of our library means that one thread (perhaps the main Java application thread) can be in the middle of creating or using this obsolete surface when the alt-tab event occurs. Given the constraints of multithreaded programming, there is no good place for us to put in a fail-safe check to make sure that we do not ever call EndScene when the alt-tab event has occurred. I am refining the native app to chase down potential solutions and will attach the app when I have something concise that demonstrates the problem (and hopefully the fix). ###@###.### 2002-10-02 I have attached a native app, d3dRadeonCrashTest2MT, which demonstrates the problem and fix pretty effectively. The problem boils down to the following: If we create a surface after the primary has gone into a lost state, set this offscreen surface to be the render target of the d3d device (which was created off of the obsolete primary), and render to that d3d device, then the system reboots or hangs. The fix is as follows: At offscreen surface creation time, check whether the primary is valid. If it is not (IsLost() returns an error), then restore it. During that restoration, also recreate the d3d device (if there is already a d3d device). If that restoration is successful, recreate the offscreen surface. if anything goes wrong during this process (such as: the primary cannot simply be restored and must be recreated), fail the offscreen surface creation and let stuff happen unaccelerated until the normal surface recreation process kicks in at some later time. An example of this kind of failure is when a fullscreen app is minimized; we cannot simply restore the primary because we do not have control of the screen. An important part of this fix is to always recreate the d3d device (if one exists already) whenever the primary is restored. This way, if the primary is restored by any other caller than the offscreen surface creation function, then both primary and d3d device will be in a good state whenever we go to use them next. The attached application should show the problem on many systems, including some non-Radeon systems. The application also has the fix in it; if you run the app with the flags: -restorePrimary -restoreD3d then we automatically check primary->IsLost() after the offscreen surface creation and restore the primary along with the d3d device before proceeding. Note that the application mimics the multithreading issues of the jdk by having a separate thread creating and rendering into the offscreen surface. Prior to writing the application to use multiple threads, i thought it would be possible to trap the windows event WM_ACTIVATE and perform any necessary surface restorations at that time. But in a multithreaded app, you cannot guarantee that another thread has not already created an invalid offscreen surface by the time the Windows event thread has received the WM_ACTIVATE message. ###@###.### 2002-10-28
28-10-2002