United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6459844 test java/awt/FullScreen/BufferStrategyExceptionTest/BufferStrategyExceptionTest.java fails on Suse
JDK-6459844 : test java/awt/FullScreen/BufferStrategyExceptionTest/BufferStrategyExceptionTest.java fails on Suse

Details
Type:
Bug
Submit Date:
2006-08-14
Status:
Closed
Updated Date:
2010-10-14
Project Name:
JDK
Resolved Date:
2008-06-09
Component:
client-libs
OS:
linux_suse_sles_9.3,linux
Sub-Component:
2d
CPU:
x86
Priority:
P4
Resolution:
Fixed
Affected Versions:
6,7
Fixed Versions:
6u10 (b26)

Related Reports
Duplicate:
Relates:
Relates:

Sub Tasks

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

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.
                                     
2006-08-14
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).
                                     
2006-08-21
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.)
                                     
2008-05-22



Hardware and Software, Engineered to Work Together