JDK-4984042 : Reliability: SwingBasher throws OutOfMemoryError
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 5.0
  • Priority: P2
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: linux_redhat_2.1
  • CPU: x86
  • Submitted: 2004-01-27
  • Updated: 2004-04-12
  • Resolved: 2004-04-12
Related Reports
Relates :  
JDK-5030149 - RAS - Tiger reliability testsuite(SwingBasher) throws OutOfMemoryError
Relates :  
JDK-4836639 - Creating components in XP L&F throws OutOfMemoryError.
Description
SwingBaher is throwing the OutOfMemoryError Exception on RHAS 2.1 and WinXP after 29th loop when run continuously for Reliability testing.

Location for Swingbasher: 

/net/sqindia/export/disk02/swing/workspaces/jfc_tiger_ws/swing_ws/swing/src/merlin/Automated/Reliability/SwingBasher

Steps to reproduce:

1. Set JAVA_HOME to b32a
2. Set SB_TIMELIMIT to 4320 (72 Hours i.e.)
3. sh runnit.sh


//Error Log
Started Loop #27 at Tue Jan 20 17:49:20 IST 2004 with Metal
Generated Performance Report. See Linux_jdsn5_SwingBasherResultsSBPerfReport-1.5.0-beta-b32a
Started Loop #28 at Tue Jan 20 18:10:40 IST 2004 with CDE/Motif
Generated Performance Report. See Linux_jdsn5_SwingBasherResultsSBPerfReport-1.5.0-beta-b32a
Started Loop #29 at Tue Jan 20 19:22:12 IST 2004 with Metal
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
gnumake: *** [runloop] Error 1
//

Try /net/sqindia.india.sun.com/export/disk02/swing/workspaces/jfc_tiger_ws/swing_ws/swing/src/merlin/Automated/Reliability/SwingBasher

I am also attaching the tar for SwingBasher.

###@###.### 2004-02-11
Comments
EVALUATION Mike - can you try running this to narrow in on where the leak occurs? Then feel free to reassign to the appropriate party. thanks! ###@###.### 2004-02-06 The path to the test /net/sqindia/export/disk02/swing/workspaces/jfc_tiger_ws/swing_ws/swing/src/merlin/Automated/Reliability/SwingBasher cannot be accessed on the network from Santa Clara. Please provide a path where it can be accessed or attach the test to the bug. ###@###.### 2004-02-06 The SwingBasher switches back and forth between Look and Feels (plafs). Each time it switches between plafs, the previous plaf is uninstalled, but it fails to clear all the references to its class instances, so the memory for those instances does not get garbage collected, leading to the OutOfMemoryError. Optimizit run on SwingSet shows about 80 different classes with instances that are not being garbage collected after switching plafs and forcing garbage collection. For example, instances of MotifMenuItemUI are not getting garbage collected after switching to the Metal plaf. Apparently some menus that were created are not getting garbage collected. Identifying all the guilty references and fixing them will take an unknown amount of time. In the meantime, it could be suggested to the test team that it is not realistic to have SwingBasher switch back and forth between plafs repeatedly for many hours, because that is not something a typical application would do, so the memory leak would not normally be encountered. Maybe they could change the SwingBasher so it does not switch back and forth between plafs and see if the test then runs to completion. ###@###.### 2004-02-11 See also: 4836639. ###@###.### 2004-03-01 ###@###.###, more information has come in (see Comments section) suggesting this is not related to look and feel switching. I'm assigning back to you to investigate. I will be assigning 4836639 to ###@###.###. Perhaps the two of you can discuss these to see if they're related. ###@###.### 2004-03-09 The BugTraq Description says the bug reproduces in build 32a. I verified the bug also reproduces in build 32. Identifying the build the bug started with would help us identify the code changes that may have caused it. Which build did the bug start with? ###@###.### 2004-03-11 I tested with the attached version of SwingBasher which does the multiple Look & Feel testing. The bug appears to be fixed in the Swing nightly build. There have been no OutOfMemoryError exceptions. My testing of SwingBasher on the Swing nightly build shows: Solaris 8: SwingBasher ran 72 hours, 492 Loops. Windows 2000: SwingBasher ran 72 hours, 335 Loops. Linux RHAS: SwingBasher ran 72 hours, 473 Loops. The bug should not be present in the next promoted build b43. Requesting Sundar (###@###.###) to verify this. ###@###.### 2004-03-15 ###@###.### 2004-03-17 According to the Evaluation for 5030149, this bug is fixed in b43. ###@###.### 2004-04-12
11-06-2004