JDK-6459844 : test java/awt/FullScreen/BufferStrategyExceptionTest/BufferStrategyExceptionTest.java fails on Suse
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6,7
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: linux,linux_suse_sles_9.3
  • CPU: x86
  • Submitted: 2006-08-14
  • Updated: 2010-10-14
  • Resolved: 2008-06-09
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
6u10 b26Fixed
Related Reports
Duplicate :  
JDK-6570758 - REGRESSION: 1.6 throws InternalError when trying to exit full screen exclusive mode, Linux
Relates :  
JDK-6459841 - test java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java fails on Suse
Relates :  
JDK-6307416 - Memory consumption increases every time I push a frame to FS mode and restore it back, Linux
Description
the test fails wiht timeout because of OutOfMEmoryError (log is attached)
I can reproduce the same issue with my test. I am running a fullscreen application on SuSE 10.0 which cycles  through all the graphics configs and graphics devices. For each GC, it creates a frame, pushes it into FS mode and  disposes the frame. When I monitored this through Jconsole, I found  that the memory consumption is going steeply and garbage collection  is not performed. Eventually it throws OutOfMemoryError after some  loops.

I tried to narrow down the problem and found that the problem  disappears if I call setFullScreenWindow(null) before disposing the  window. But If I don't call the above method and just dispose the  window directly, there seems to be a memory leak. I reproduced it on SUSE 10 with Nvidia  GeForce FX5900 and ATI Radeon 9600, both with the latest drivers  installed. Reproduced with JDK7 as well as JDK6-FCS. I have attached my test to the bug report.
Comments
EVALUATION We will fix this particular problem by avoiding the actual setDisplayChange() call when the given mode is the same as the current mode. This avoids the OOME so that this test and other apps that use only setFullScreenWindow() (and do not change the display mode) will now work properly. However, the underlying cause of the OOME when calling setDisplayMode() repeatedly is still present and will be handled under a separate bug (6459841). (That issue is less important because it only affects testcases that really stress the calling of setDisplayMode() frequently, which is not a common scenario in the real world.)
22-05-2008
EVALUATION The test itself doesn't call setDisplayMode. So it appears that we call it during the setFullScreenWindow() call (as per your evaluation). Looks like we do it when restoring the original display mode. In this case the display mode doesn't change, so there is no need for calling setDisplayMode. We do the same thing on windows, except that in Win32GD.setDisplayMode we check if the passed display mode is the same as the current mode, and noop in this case. We don't do this on Unix, though (see X11GD.setDisplayMode()) - not sure why - so the display mode change event gets generated, and so on. Anyway, what I'm saying is that this test shouldn't really be causing all that carnage with display mode changes etc. Also, on my solaris system I can't reproduce the failure because the display mode changes aren't supported. Reassigning back to unix FS engineer (aka the victim).
21-08-2006
EVALUATION The OOME comes from the fact that the testcase creates a new Frame (--> a new BufferStrategy --> a new VolatileImage --> a new "backup" BufImageSurfaceData) for each iteration. For each iteration we have: --> X11GD.setFullScreenWindow() --> X11GD.setDisplayMode() --> VSM.displayChanged() --> VSM.getBackupSurface() Each "backup" surface created is about the size of the screen (in my case that's 1600x1200) and is created in the Java heap, so if these are not disposed quickly, they can easily exhaust the Java heap and cause the OOME. I'm not sure what we can do to prevent this, but it's not a scenario that most fullscreen apps are likely to run into. Transferring back to the test's owner while we give this some more thought.
14-08-2006