JDK-4910323 : REGRESSION: Regression-cte 4343272/MiniGnip.java fails
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 5.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_9,solaris_10,windows_xp
  • CPU: x86
  • Submitted: 2003-08-21
  • Updated: 2017-05-19
  • Resolved: 2004-03-15
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.
Other
5.0 b43Fixed
Related Reports
Relates :  
JDK-4662231 - REGRESSION: Yet another java.awt.dnd.DropTarget causing JNI Global Reference lea
Relates :  
JDK-4913044 - REGRESSION: AWTComponentTest/src/Automated/4379291/ComponentLeakTest fail in b16
Relates :  
JDK-4343272 - Yet another java.awt.dnd.DropTarget causing JNI Global Reference leak?
Description

Name: vsR10238			Date: 08/21/2003


Filed By       : J2SE-SQA [###@###.###
JDK            : JDK1.5.0-b15
Testbase       : Regression-cte
Platform[s]    : Windows XP Home, Solaris 10 (sparc) (GNOME), Solaris 9 (x86) (CDE)
switch/Mode    : -client, -server
Falling test[s]:
         CTE_REGTEST/Generic/4343272/MiniGnip.java

Regression-cte CTE_REGTEST/Generic/4343272/MiniGnip.java test fails with JDK1.5.0-b15,b14,b13.
The test passes with JDK1.5.0-b12, JDK1.4.2 (tested with b28).

On Solaris-Sparc, Solaris-x86, Windows the test fails with the output provided in the Test output (jtr part)
section of the description.

On 32 bit Linux (tested with RH2.1AS, RH7.3) the test fails due to another reason:

Error:
"Menu pushing" action has not been produced in 60016 milliseconds
Error:
Timeout for "Menu pushing" action has been expired. Thread has been interrupted.
java.lang.RuntimeException: Failed
	at Test4343272.main(Test4343272.java:74)


Test source location:
=====================
/net/jdk/export/jpse04/Regression/1.5.0/test/CTE_REGTEST/Generic/4343272/MiniGnip.java

jtr file location:
==================
/net/jtgb4u4c.sfbay/export/sail15/results.2/tiger/b15/regtest/x86/sol9_x86_cde_smp_linux-6/workDir/cte/CTE_REGTEST/Generic/4343272/MiniGnip.jtr

How to reproduce:
=================
Run the following script (you may need to change its variables)

--- script start ---
#!/bin/sh

RESULT_DIR=`pwd`
WORK_DIR=$RESULT_DIR/workDir/test
REPORT_DIR=$RESULT_DIR/reportDir
JT_HOME="/net/linux-15/export/home/java/jct"
JAVA_HOME="/net/linux-15/export/home/java/jdk1.5.0/x86"
TEST_BASE_PATH="/net/linux-15/export/home/java/regtest.tiger/cte"

TESTWITH=$JAVA_HOME
TESTJAVA=$JAVA_HOME

JTOPTS="-server"
TESTVMOPTS="-server"

CLASSPATH="$JT_HOME/classes:$JT_HOME/lib/javatest.jar:$JT_HOME/lib/jtreg.jar:$JT_HOME/jemmy/jemmy.jar"

export JAVA_HOME
export JT_HOME
export TESTWITH
export CLASSPATH

mkdir -p $WORK_DIR/scratch 2>&1
mkdir -p $WORK_DIR/jtData 2>&1
mkdir -p $REPORT_DIR 2>&1

#rm $WORK_DIR/jtData/ResultCache.jtw 2>&1

cd $WORK_DIR/scratch

$JAVA_HOME/bin/java -cp $CLASSPATH $JTOPTS -DenvVars=TESTJAVAHOME=$JAVA_HOME,TESTVMOPTS=$TESTVMOPTS,DISPLAY=:0,HOME=$HOME/.regtest,PATH=/bin:/usr/bin,CPAPPEND=$JT_HOME/jemmy/jemmy.jar,TZ=,LC_ALL=en_US,LC_CTYPE=en_US,LANG=en_US,LPDEST= -DDISPLAY=:0 -DlocalHost="linux-6" -Dprogram=jtreg com.sun.javatest.regtest.Main -a -v default -batch -params -w "$WORK_DIR" -r "$REPORT_DIR" -t "$TEST_BASE_PATH" "$TEST_BASE_PATH/CTE_REGTEST/Generic/4343272/MiniGnip.java"

--- script end ---


Test output (jtr part):
=======================
Trace:
Frame "Frame with title "Main frame10"" has been opened in 1 milliseconds
     MainWindow[frame10,280,280,198x55,invalid,layout=java.awt.BorderLayout,title=DT Main
frame10,resizable,normal,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,5,24,188x26,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=449,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
Memory Round1: 6212984
Memory Round2: 11526792
Increment    : 85.527466%
Test Failed
----------System.err:(13/672)----------
java.lang.RuntimeException: Failed
	at Test4343272.main(Test4343272.java:74)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:324)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:82)
	at java.lang.Thread.run(Thread.java:549)

JavaTest Message: Test threw exception: java.lang.RuntimeException: Failed
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.RuntimeException: Failed
result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Failed


test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Failed


Specific machine info:
======================
Hostname: linux-21
OS: Windows XP Home
Hostname: linux-6
OS: Solaris 9 (x86) (CDE)
Hostname: linux-8
OS: Solaris 10 (sparc) (GNOME)



======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b43 tiger-beta2 VERIFIED IN: tiger-beta2
24-08-2004
SUGGESTED FIX Name: azR10139 Date: 02/20/2004 ------- JMenuItem.java ------- *** /tmp/sccs.fAaqov Fri Feb 20 19:39:10 2004 --- JMenuItem.java Fri Feb 20 19:39:01 2004 *************** *** 833,868 **** AccessibleJMenuItem() { super(); JMenuItem.this.addChangeListener(this); - // TIGER - 4848220 - MenuSelectionManager.defaultManager().addChangeListener(new AccessibleMenuItemChangeListener()); - } - - /* - * Listener for menu item selection changes - * TIGER - 4848220 - */ - private class AccessibleMenuItemChangeListener - implements ChangeListener { - - public void stateChanged(ChangeEvent e) { - // get the selected menu item from the MenuSelectionManager - MenuElement [] path = - MenuSelectionManager.defaultManager().getSelectedPath(); - if (path.length > 0) { - // fire a PropertyChangeEvent is this is the - // menu item that was selected. - Object menuItem = path[path.length - 1]; - if (JMenuItem.this == menuItem) { - firePropertyChange( - AccessibleContext.ACCESSIBLE_STATE_PROPERTY, - null, AccessibleState.FOCUSED); - } - } - } - } - /** * Get the role of this object. * --- 833,840 ---- *************** *** 873,878 **** --- 845,863 ---- return AccessibleRole.MENU_ITEM; } + private void fireAccessibilityFocusedEvent(JMenuItem toCheck) { + MenuElement [] path = + MenuSelectionManager.defaultManager().getSelectedPath(); + if (path.length > 0) { + Object menuItem = path[path.length - 1]; + if (toCheck == menuItem) { + firePropertyChange( + AccessibleContext.ACCESSIBLE_STATE_PROPERTY, + null, AccessibleState.FOCUSED); + } + } + } + /** * Supports the change listener interface and fires property changes. */ *************** *** 885,890 **** --- 870,879 ---- firePropertyChange( AccessibleContext.ACCESSIBLE_STATE_PROPERTY, null, AccessibleState.ARMED); + // Fix for 4848220 moved here to avoid major memory leak + // Here we will fire the event in case of JMenuItem + // See bug 4910323 for details [zav] + fireAccessibilityFocusedEvent(JMenuItem.this); } } else { if (isArmed) { *************** *** 930,936 **** firePropertyChange( AccessibleContext.ACCESSIBLE_STATE_PROPERTY, null, AccessibleState.CHECKED); ! } } else { if (isSelected) { isSelected = false; --- 919,930 ---- firePropertyChange( AccessibleContext.ACCESSIBLE_STATE_PROPERTY, null, AccessibleState.CHECKED); ! ! // Fix for 4848220 moved here to avoid major memory leak ! // Here we will fire the event in case of JMenu ! // See bug 4910323 for details [zav] ! fireAccessibilityFocusedEvent(JMenuItem.this); ! } } else { if (isSelected) { isSelected = false; ======================================================================
24-08-2004
EVALUATION Name: dsR10078 Date: 08/29/2003 I reproduced this bug on Solaris 8, Linux RH AS 2.1 and Windows 2000 with 1.5.0b17. The bug description states that on Linux the test failure is different. The reason is that the test uses Jemmy library to emulate user actions and on some window managers (e.g. GNU Window Maker) jemmy fails to move frames and so fails to select appropriate menu items. If the test is run on Linux and CDE, it fails in the same way as on Solaris and Windows. Running the test with OptimizeIt shows that MainWindow instances are never collected, since they are referenced from a static variable in javax.swing.MenuSelectionManager. Here is the reference list for MainWindow on Solaris/Linux: MainWindow 0xf221bed8 parent of javax.swing.JRootPane 0xf221c110 parent of javax.swing.JLayeredPane 0xf221c440 parent of javax.swing.JMenuBar 0xf221c950 menuBar of javax.swing.plaf.metal.MetalMenuBarUI 0xf221cad0 this$0 of javax.swing.plaf.basic.BasicMenuBarUI$Handler 0xf221cb10 element of Object[] 0xf221cf18 listenerList of javax.swing.event.EventListenerList 0xf221cdf0 listenerList of javax.swing.DefaultButtonModel 0xf221cdd0 model of javax.swing.JMenu 0xf221cbd8 accessibleParent of javax.swing.JMenuItem$AccessibleJMenuItem 0xf221d250 this$1 of javax.swing.JMenuItem$AccessibleJMenuItem$AccessibleMenuItemChangeListener 0xf221d2d0 element of Object[] 0xf2436688 listenerList of javax.swing.event.EventListenerList 0xf1faa5a8 listenerList of javax.swing.MenuSelectionManager 0xf1faa540 Static variable of class javax.swing.MenuSelectionManager this$0 of MainWindow$1 0xf221d240 this$0 of MainWindow$CloseCommand 0xf221d518 this$0 of MainWindow$Meg 0xf221d528 On Solaris and Linux I verified that if MiniGnip is modified so that MainWindow doesn't contain menubar, all MainWindow instances are collected and the test passes. The reference list on Windows is the same except for JNI reference from the native code: MainWindow 0xf221bed8 JNI reference (thread AWT-Windows) parent of javax.swing.JRootPane 0xf221c110 parent of javax.swing.JLayeredPane 0xf221c440 parent of javax.swing.JMenuBar 0xf221c950 menuBar of javax.swing.plaf.metal.MetalMenuBarUI 0xf221cad0 this$0 of javax.swing.plaf.basic.BasicMenuBarUI$Handler 0xf221cb10 element of Object[] 0xf221cf18 listenerList of javax.swing.event.EventListenerList 0xf221cdf0 listenerList of javax.swing.DefaultButtonModel 0xf221cdd0 model of javax.swing.JMenu 0xf221cbd8 accessibleParent of javax.swing.JMenuItem$AccessibleJMenuItem 0xf221d250 this$1 of javax.swing.JMenuItem$AccessibleJMenuItem$AccessibleMenuItemChangeListener 0xf221d2d0 element of Object[] 0xf2436688 listenerList of javax.swing.event.EventListenerList 0xf1faa5a8 listenerList of javax.swing.MenuSelectionManager 0xf1faa540 Static variable of class javax.swing.MenuSelectionManager this$0 of MainWindow$1 0xf221d240 this$0 of MainWindow$CloseCommand 0xf221d518 this$0 of MainWindow$Meg 0xf221d528 The JNI reference from native code on Windows is a separate problem that can be reproduced with a minimal test case: ------------------------------------------------------------------------ import java.awt.Frame; public class Test { public static void main(String[] args) throws InterruptedException { for (int i = 0; i < 10; i++) { Frame frame = new Frame(); frame.setVisible(true); Thread.sleep(1000); frame.dispose(); } Thread.sleep(100000); } } ------------------------------------------------------------------------ Run the test case with OptimizeIt, wait until all frames are shown and disposed, then invoke GC and look at reference graphs for java.awt.Frame. ###@###.### 2003-08-29 ====================================================================== Name: ssR10077 Date: 09/10/2003 ###@###.### 2003-09-10 The remaining Win32 problem is the same as described in 4913044 ====================================================================== We had this reopened, since we can still reproduce the failure. ###@###.### 2003-10-22 Name: rpR10076 Date: 10/23/2003 The win32-specific problem was fixed, now the references are only kept from the Swing code, as described in the evaluation above. Reassigning to Swing. ###@###.### ====================================================================== Name: azC76091 Date: 10/31/2003 After inserting of some debug output into swing code i found that the problem lays inside a jemmy test suite. The jemmy test suite does not makes sure that all the events generated by the user input are processed before changing the state of the components. And that is what happened because of this: 1. The new JFrame is being created. 2. This frame is shown on screen. 3. It is moved to the new position. 4. Not waiting for all the events generated by this move is processed test trying to open the menu from the menubar in the frame. 5. The popup is being opened and instantly the frame received COMPONENT_MOVED event from the last move. 6. The BasicPopupMenu$MouseGrabber class receives this event and closes popup. 7. Test starts to wait until popup menu is open. But it's already being opened and already closed because the COMPONENT_MOVED event. 8. Test failed by timeout. This happens only on XToolkit. The test or jemmy testsuite must be corrected to work with the events more accurately. ###@###.### 10/31/2003 ====================================================================== Name: dsR10078 Date: 01/24/2004 The memory leak in javax.swing.MenuSelectionManager described in the evaluation above is reproducible even when test case is executed manually. I verified that the problem still manifests with JDK1.5.0b33 and the reference graph is the same. Steps to reproduce the bug manually: 1.java MiniGnip. 2.A frame with title "Control Window" will appear. 3.Repeat 5 times: 3.1.Select File->Open menu item. 3.2.A new frame will appear. 3.3.In the new frame select File->Drop target menu item. 4.Dispose all the 5 frames created at step 5. 5.Select File->Run GC menu item 4 times. 6.Note the heap size indicated by the label "Heap". 7.Repeat steps 3,4,5. 8.If the heap size in the label increased by more than 5 percents the test fails. Since references to the disposed frames are kept only from Swing code, i'm reassigning to Swing for further investigation. ###@###.### 2004-01-24 ====================================================================== Name: azR10139 Date: 02/20/2004 This memory leak was introduced with the fix for bug 4848220. In the constructor of the JMenuItem$AccessibleJMenuItem inner class we are adding the change listener to the MenuSelectionManager by calling MenuSelectionManager.defaultManager().addChangeListener(new AccessibleMenuItemChangeListener()); But MenuSelectionManager keeps the listeners list in the static member and because this listener is never being removed from MenuSelectionManager this leads to situation when JFrame with the menubar will never been GC'ed. The idea of suggested fix is to move this functionality to the MenuItem$AccessibleJMenuItem.stateChanged() method. As this class is being registered as change listener in the JMenuItem itself this method will be called when menuitem will be selected/deselected. And because there are no external links to this class from the outside JMenuItem class this will not cause memory leak. ###@###.### 02/20/2003 ======================================================================
20-02-2003