JDK-4836639 : Creating components in XP L&F throws OutOfMemoryError.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.0,1.4.1,1.4.2
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_2000,windows_xp
  • CPU: generic,x86
  • Submitted: 2003-03-24
  • Updated: 2017-05-16
  • Resolved: 2004-04-24
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 beta2Fixed
Related Reports
Duplicate :  
JDK-4748141 - First JInternalFrame added to a JDesktop causes memory leak
Relates :  
JDK-4984042 - Reliability: SwingBasher throws OutOfMemoryError
Description
Creating a large number of JInternalFrames in SwingSet2 is causing the application to throw an OutOfMemoryError. This happens when running the scenario on a XP L&F. To reproduce, do the following:

- Create about 200+ internal frames while switching between JLF and the 
  Windows L&F (XP L&F since I was testing on an XP system). I noticed that
  as the number of internal frames grew, the XP L&F became slower everytime
  you requested SwingSet2 to create a new internal frame. When I switch to
  JLF, though, I was able to click away full speed creating new internal
  frames. However, when I switched back to XP L&F, it took time for it to
  repaint, and when I monitored the memory usage in task manager, I can see
  the memory usage grow slowly. On my machine, at about 80K to 85K, the 
  system finally threw an OutOfMemoryError when I switched from JLF to 
  XP L&F.

The problem was produced on the latest Mantis build, b18.

###@###.### 2003-03-24
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-beta2
17-09-2004
EVALUATION XP uses a lot of images for painting. It looks like under XP we may be be keeping around refs to things we no longer need. I will run this under OptimizeIt to find more conclusive information. ###@###.### 2003-03-24 I noticed under OptimizeIt that we leak a few components when we uninstall the windows l&f. This only happens when we switch the l&f. Since it is not common to switch between l&fs multiple times and it is not common to create so many internal frames I am commiting this to a later release. ###@###.### 2003-03-26 Ran OptimizeIt again with 1.5b26 and the problem still exists. ###@###.### 2003-11-18 May be related to 4984042. ###@###.### 2004-03-01 Name: sh120115 Date: 03/09/2004 ###@###.### is working on 4984042. It would be interesting to discuss any possible relation to that bug. ###@###.### 2004-03-09 ====================================================================== When changing from the Windows LAF to Metal, we're leaking several WindowsInternalFrameTitlePanes (and related objects). According to OptimizeIt, the remaining references look like: this+0 of com.sun.java.swing.plaf.windows.WindowsInternalTitleFrameTitlePane$WindowsPropertyChangeHandler. This indicates that the non-static inner class, WindowsPropertyChangeHandler, is holding onto its enclosing WindowsInternalTitleFrameTitlePane. Some experimentation shows that when switching to the Windows LAF and back, two WindowsPropertyChangeHandler property change listeners are added, but only one is removed. So, for each JInternalFrame, we end up with an extra WindowsPropertyChangeHandler (which is holding onto a WindowsInternalTitleFrameTitlePane) on the listener list. Why are two WindowsInternalTitleFrameTitlePane$WindowsPropertyChangeHandlers created for each JInternalFrame, and why is only one removed? The answer lies in the fact that the WindowsInternalFrameTitlePane is used not only as the internal frame's title pane, but also as its desktop icon. From WindowsDesktopIconUI.java: protected void installComponents() { iconPane = new WindowsInternalFrameTitlePane(frame); desktopIcon.setLayout(new BorderLayout()); desktopIcon.add(iconPane, BorderLayout.CENTER); ... The WindowsInternalFrameTitlePane superclass, BasicInternalFrameTitlePane, contains the methods for installing and uninstalling of PropertyChangeListeners. When a JInternalFrame updates its UI, it also updates the UI of its desktop icon. Switching away from the Windows LAF results in a call to BasicDesktopIconUI.uninstallUI(). However, BasicDesktopIconUI has no idea that underneath, we're actually using a WindowsInternalFrameTitlePane, so there is never a call to BasicInternalFrameTitlePane.uninstallListeners(). Thus, we're stuck with the extra listener. I prototyped a fix that adds a WindowsDesktopIconUI.uninstallUI() method, which removes the listener. I suspect this may be a problem for other LAFs. I'll investigate that next. ###@###.### 2004-03-22 The MotifLookAndFeel has a similar leak, the Java and GTK Look And Feels do not. ###@###.### 2004-03-29
22-03-2004