JDK-4351377 : crash in screen rendering on MT apps on win32 after display mode switch
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2000-07-07
  • Updated: 2001-01-19
  • Resolved: 2001-01-19
Related Reports
Relates :  
JDK-4345586 - Rendering incorrect after switching display modes (win32 only)
Description
There is the potential for a crash when running an app that has more than
one thread rendering to the screen.  The problem can occur when there
is a display mode switch (e.g., the user changes from one bit depth
to another while the Java app is running).
Comments
EVALUATION The problem lies in the nature of surface loss and restoration. In particular, we have one "primary" surface (the onscreen surface) per application; this is a global variable. When there is a display mode switch, that surface is "lost" (directDraw terminology) and must be re-created. This is done in one rendering thread, but the other thread has no way of knowing that the surface is going away and being recreated. So the next time that second thread calls into native code and attempts to do something with the primary surface, it will make a call into the function table of a garbage object (the old primary surface). We have to have a way of synchronizing on the primary surface and/or notifying all appropriate objects when the primary surface has changed. chet.haase@Eng 2000-07-07 --------------------------- This bug was fixed along with several other bugs (e.g., 4345586) in a restructuring of the ddraw code several months ago. The bug has not been reproducible since then, so I will close it as "not reproducible". The key to the fix of this bug was to leave old primary surfaces around for those threads still attempting to use them, but to create new ddraw objects/primaries for new display modes. Calls to the old primaries would fail with DDERR_WRONGMODE, which would then trigger events that would force a change to the new display mode ddobject. But by leaving those old primaries around, we at least allow the calls to go through unhindered and don't risk dereferencing garbage pointers. chet.haase@Eng 2001-01-19
19-01-2001