JDK-6325718 : NullPointerException at sun.awt.image.VolatileSurfaceManager.displayChanged
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: linux,linux_suse_sles_10
  • CPU: x86
  • Submitted: 2005-09-19
  • Updated: 2011-03-24
  • Resolved: 2011-03-24
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 7
7Resolved
Related Reports
Duplicate :  
JDK-6529869 - Calling gd.setFullScreenWindow(null) throws a NPE on SuSE 10
Relates :  
JDK-6538511 - NPE when removing one of the monitors at runtime, win32
Relates :  
JDK-6459841 - test java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java fails on Suse
Relates :  
JDK-6290240 - Fullscreen window is not restored properly when restoring it frome Exclusive Mode to Normal Mode
Description
Java version: Mustang b49 and later, not reproducible on b42-b48
Platform: reproducible on SuSE 9.2 & 9.3, XToolkit
Reproducibility: quite often (3/4).

When running attached test on XToolkit, mustang b49 and later following exception is generated
java.lang.NullPointerException
        at sun.awt.image.VolatileSurfaceManager.displayChanged(VolatileSurfaceManager.java:310)
        at sun.awt.SunDisplayChanger.notifyListeners(SunDisplayChanger.java:102)
        at sun.awt.X11GraphicsEnvironment.displayChanged(X11GraphicsEnvironment.java:1062)
        at sun.awt.X11GraphicsDevice.setDisplayMode(X11GraphicsDevice.java:365)
        at sun.awt.X11GraphicsDevice.setFullScreenWindow(X11GraphicsDevice.java:269)
        at FrameFullScreenTest.fullScreenSameDevice(FrameFullScreenTest.java:129)
        at FrameFullScreenTest.<init>(FrameFullScreenTest.java:22)
        at FrameFullScreenTest.main(FrameFullScreenTest.java:157)

See 6290240 for details on test.

This bug is reproducible starting from b49 but similar exceptions can be thrown on earlier builds.
Comments
EVALUATION Suse 9 is not a supported platform in JDK 7. Testing using Suse 10 did not reproduce the problem. Marking as not reproducible.
24-03-2011
SUGGESTED FIX *** /tmp/geta8624 Thu May 22 14:32:48 2008 --- VolatileSurfaceManager.java Thu May 22 14:03:45 2008 *************** *** 313,328 **** return; } lostSurface = true; ! if (sdAccel != null) { ! // First, nullify the software surface. This guards against ! // using a SurfaceData that was created in a different ! // display mode. ! sdBackup = null; ! sdCurrent = getBackupSurface(); ! // Now, invalidate the old hardware-based SurfaceData ! SurfaceData oldData = sdAccel; ! sdAccel = null; ! oldData.invalidate(); } // Update graphicsConfig for the vImg in case it changed due to // this display change event --- 313,321 ---- return; } lostSurface = true; ! SurfaceData oldData = sdAccel; ! if (oldData != null) { ! oldData.setSurfaceLost(true); } // Update graphicsConfig for the vImg in case it changed due to // this display change event
22-05-2008
EVALUATION Dmitri and I looked at the code in VolatileSurfaceManager.displayChanged() and it seems that it was written long ago to combat or perhaps workaround some issues caused by the complicated DirectDraw pipeline architecture. The new D3D pipeline architecture is much simpler by comparison, and it seems that this code is no longer necessary. The suggested fix uses a simpler approach of just calling setSurfaceLost(true) on sdAccel in the case of displayChanged(). Creation of the backup surface can happen lazily as part of the validate() process. I've verified that this testcase no longer throws the NPE with the suggested fix in place. (It also solves the problem reported in 6459841 since we no longer actively create the backup surface on display changes.) Since this code is in an area that is historically tricky to get right, I suggest we fix this in 7 once the D3D pipeline has been forward ported from 6u10 to 7. That will give us sufficient time to make sure that this is the best fix for all platforms.
22-05-2008
EVALUATION I've seen a similar stack trace reported on Windows in 6319745, although that bug report claims that it was not reproducible with b49, but rather started in b51. In both cases there must be some multithreading issues at play: in displayChanged(), we first check that sdAccel != null and then we invalidate the old accelerated surface like this: SurfaceData oldData = sdAccel; sdAccel = null; oldData.invalidate(); So clearly sdAccel is being set to null sometime before this block and sometime after the !=null check. More investigation required. Also, 2D did not integrate into b49, so it's possible that some timing change (possibly from AWT) is causing this failure.
19-09-2005