JDK-6337388 : CTE_REGTEST/Generic/4347545 fails, mustang
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-10-15
  • Updated: 2010-08-06
  • Resolved: 2005-11-25
Related Reports
Duplicate :  
JDK-6351698 - Regression: 4506928 testcase is passing with 142_10-b03 but failing with 142_11-b01
Duplicate :  
JDK-6347637 - Some MultiMonitor tests got OutOfMemoryError in mustang b58 in GeForce6600 card
Relates :  
JDK-6356118 - CTE_REGTEST/Generic/4347545 fails on Solaris
Description
J2SE            : mustang b56
Platform[s]     : Windows XP Home SP2 with IE6 browser
Failing Tests   : CTE_REGTEST/Generic/4347545

Testcase and instruction available at  :
==============================
/net/jdk/export/jpse04/Regression/1.6.0/test/CTE_REGTEST/Generic/4347545
StaticTest.html
StaticTest.java

Testcase Instructions :
==============================
TEST - 4347545
 -- First instance of (J)Applet is not gc'ed
Make sure that proper version of plugin is installed
Instructions:

1. Open IE / Netscape browser
2. Open the following file into browser
   StaticTest.html
3. Once applet is loaded, click 'Reload'/'Refresh' button in browser, 
   couple of times (Until you see 'finalized...' in java console)

Check:
If you see 'finalized 0' in Java plugin console, test passed
otherwise test failed

Test Result:
==============================
'finalized 0' does not diplayed in Java Console
Comments
EVALUATION Verified to be a duplicate of 6351698. For the Solaris case, the root cause of the problem must be completely different so a new bug should be opened.
25-11-2005
EVALUATION This bug (at least, the original windows part) appears to be a duplicate of 6351698: 4506928 testcase is passing with 142_10-b03 but failing with 142_11-b01 or 6327297: OutOfMemoryError after running a few SwingSet2 Applet I'm reassigning it to the awt team and let them sort it out.
23-11-2005
EVALUATION I can reproduce the problem (some frames not being collected) on solaris as well. But here I see a bunch of real references, for example: Static reference from sun.awt.X11.XGlobalCursorManager.manager (from class sun.awt.X11.XGlobalCursorManager) : --> sun.awt.X11.XGlobalCursorManager@0xd0b5f288 (32 bytes) (field nativeContainer:) --> AWTRenderingContents@0xd0b6ed18 (194 bytes) System Class References System Class Reference : --> class sun.awt.X11.XGlobalCursorManager (76 bytes) (static field manager:) --> sun.awt.X11.XGlobalCursorManager@0xd0b5f288 (32 bytes) (field nativeContainer:) --> AWTRenderingContents@0xd0b6ed18 (194 bytes) or, for another instance: Java Static References Static reference from java.awt.KeyboardFocusManager.activeWindow (from class java.awt.KeyboardFocusManager) : --> java.awt.Frame@0xd0b17510 (347 bytes) (field component:) --> [Ljava.awt.Component;@0xd0b27e18 (12 bytes) (Element 0 of [Ljava.awt.Component;@0xd0b27e18:) --> AWTRenderingContents@0xd0b2d568 (194 bytes) System Class References System Class Reference : --> class sun.awt.X11.XKeyboardFocusManagerPeer (76 bytes) (static field currentFocusedWindow:) --> java.awt.Frame@0xd0b17510 (347 bytes) (field component:) --> [Ljava.awt.Component;@0xd0b27e18 (12 bytes) (Element 0 of [Ljava.awt.Component;@0xd0b27e18:) --> AWTRenderingContents@0xd0b2d568 (194 bytes) System Class Reference : --> class java.awt.KeyboardFocusManager (76 bytes) (static field activeWindow:) --> java.awt.Frame@0xd0b17510 (347 bytes) (field component:) --> [Ljava.awt.Component;@0xd0b27e18 (12 bytes) (Element 0 of [Ljava.awt.Component;@0xd0b27e18:) --> AWTRenderingContents@0xd0b2d568 (194 bytes) I will need some help from awt team to determine if these references are expected. I can see that I always have at least four instances of AWTRenderingContents hanging around after I dispose of all but one frames. Not good.
23-11-2005
EVALUATION The following simplified test shows the same bug: import java.awt.Canvas; import java.awt.Frame; import java.awt.Graphics; import java.awt.GraphicsConfiguration; import java.awt.Window; class AWTRenderingContents extends Canvas { public AWTRenderingContents(GraphicsConfiguration gc) { super(gc); } public void paint (Graphics g) { } public static void main (String args[]) { for (int i = 0; i < 20; i++) { Frame f = new Frame("AWTRenderingContents"); f.setSize(400, 400); f.setLocation(10, 10); f.add(new AWTRenderingContents(f.getGraphicsConfiguration())); f.addWindowListener(new java.awt.event.WindowAdapter() { public void windowClosing(java.awt.event.WindowEvent we) { Window w = (Window) we.getSource(); w.dispose(); System.gc(); System.runFinalization(); System.gc(); System.runFinalization(); System.gc(); System.runFinalization(); System.gc(); System.runFinalization(); } }); f.setVisible(true); } } } See a duplicate bug 6347637: Some MultiMonitor tests got OutOfMemoryError in mustang b58 in GeForce6600 card
23-11-2005
EVALUATION With upgraded version of jhat (with fixed 6339417) I can see that the instances which aren't being collected are held by a single global JNI reference. Unfortunately there's seems to be no way in jhat to find out where that reference was created.
21-10-2005
EVALUATION Actually, I've discovered that sometimes the instances indeed do not get collected. Typically it happens if there was some interaction with the java console during the applet run. It's not clear why it is not getting collected. I can't find any (non-cyclic) references to the instances with jhat. Needs further investigation.
18-10-2005
EVALUATION The applet does get collected, but for some reason it takes a bit longer now than it used to. Try hitting 'g' in the java console forcing garbage collection, and the applet will be GC-ed. I think the instruction for the test needs to be updated. Please verify that focing GC disposes of the applet.
18-10-2005