JDK-6429971 : D3D: ALT + TABing a FS application crashes the VM when AA is enabled, WinXP
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-05-24
  • Updated: 2008-02-06
  • Resolved: 2006-08-18
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.
JDK 6
6 b96Fixed
Related Reports
Relates :  
JDK-6275887 - PIT:D3D: VM Crashes when using D3D with FullScreen Frame and ALT+TABing a couple of times, Win32
Description
I have a bouncing ball application which creates many ball objects on the screen when clicking the mouse. I have a volatile image to which I render all the balls and animate them. I have enabled AntiAlias when rendering the ball objects and I am running this app in FS mode. When I press ALT + TAB or the windows key after adding few ball objects, the VM crashes immediately.

This is reproducible on WinXP with Mustang-b59d and b84. This is not seen when disabling AA. This is not seen with other pipelines such as OGL and noddraw. The stack trace appears to be from D3D since D3D is enabled by default for FullScreen applications in Mustang. Would be good to fix this for mustang since it appears like a regression.

I have executed this on b83 fast_debug build with J2D_TRACE_LEVEL set to 4. I have attached the test and the log files. 

I reproduced it on Nvidia GeForce4 MX440, MX4000, FX5900 with the latest nvidia driver (84.21).
Comments
SUGGESTED FIX http://javaweb.sfbay/jcg/1.6.0-mustang/2D/6429971/
02-08-2006
EVALUATION Looks like the performance penalty isn't that bad - within 2%, so I'll go ahead with the fix.
01-08-2006
EVALUATION After running with the debug version of DirectX libraries I have verified that it actually crashes in IDirect3D7Device::DrawPrimitive() call. At the time of the crash the destination surface was lost, but the texture wasn't (it's a managed texture, so no suprise here). A solution (or, rather, a work around) here is the same it was for the other manifestation of this nvidia driver bug: check if the surface is lost prior to issuing a DrawPrimitive call. The fix works fine, reducing but not eliminating the chances of the crash - the surface could be lost just after we checked it. The workaround will rob us of some performance, but its necessity seems inevitable since nvidia boards are wide spread, the the crash is easy to reproduce. Also, similar fix is needed for the text rendering code.
31-07-2006
EVALUATION Here's the tail of the log: [I] D3DMaskFill_MaskFill [V] x=407 y=375 w=32 h=32 [V] maskoff=0 maskscan=32 [I] DDrawSurface::IsLost: dxSurface=0x3051840 [I] D3DContext::BeginScene [I] D3DContext::UploadImageToTexture [V] rect={0 , 0 , 32 , 32 } [I] DXSurface::Lock # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x73956201, pid=3276, tid=2180 # # Java VM: Java HotSpot(TM) Client VM (1.6.0-beta2-fastdebug-b83-debug mixed mod e) # Problematic frame: # C [D3DIM700.DLL+0x16201] # This looks like another manifestation of 6275887: PIT:D3D: VM Crashes when using D3D with FullScreen Frame and ALT+TABing a couple of times, Win32 The fix for the above bug covered most of of the cases where a surface could be lost, but not this particular one. The interesting thing is that we use managed texture for the mask texture, and yet it still gets lost. Here the crash happens in Direct3D's IDirectDrawSurface7::Lock call, presumably when the texture we're uploading the image to gets lost sometime during the rendering loop. Note that we do check and restore the texture at the beginning of the MaskFill method if needed (the D3DContext::GetMaskTexture() sees to that), but apparently the surface becomes lost sometime after that. The only solution I know of is to add another check for IsLost() before locking the surface. Of course, this will only narrow the window of when the surface could become lost, but there's only so much we can do working around drivers bugs. Also, since this is done inside a loop it will surely affect performance.
24-05-2006