JDK-6692197 : OutofMemory observed while loading large files into JTextArea
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6u5
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-04-22
  • Updated: 2014-11-18
Related Reports
Relates :  
Relates :  
Description
OPERATING SYSTEM(S):
Windows XP

FULL JDK VERSION(S):
java version "1.6.0_05"
Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode)

TESTCASE DESCRIPTION:

1. The application (testcase) creates a GUI with buttons to load a file
   into JTextArea or to run GC.
2. If the button to load the file is clicked, then a thread is spawned
   which creates a new JFrame Window with a JTextArea component, where
   the file can be loaded.
3. Once the file contents are loaded into the file, the JTextArea
   Window can be closed.

RECREATION INSTRUCTIONS:

  To recreate, compile MyThread.java and JTextAreaTest.java (see attachemtns)
and then run the testcase as follows:

   java JTextAreaTest

1. Launch the application, select the option to load a file.
2. Load a huge file of size (80MB-120MB) into JTextArea. Once the file
   contents are observed, close the window.
3. Repeat step 2 five or six times on a machine with 1G RAM and we
   should be able to observe the OutofMemory Error with the following
   stack trace:

java.lang.OutOfMemoryError:
at javax.swing.text.GapContent.allocateArray(GapContent.java:106)
at javax.swing.text.GapVector.resize(GapVector.java:226)
at javax.swing.text.GapVector.shiftEnd(GapVector.java:241)
at javax.swing.text.GapContent.shiftEnd(GapContent.java:355)
at javax.swing.text.GapVector.open(GapVector.java(Compiled Code))
at javax.swing.text.GapVector.replace(GapVector.java(Compiled Code))
at javax.swing.text.GapContent.insertString(GapContent.java(Inlined Compiled Code))
at javax.swing.text.AbstractDocument.handleInsertString(AbstractDocument.java(Compiled Code))
at javax.swing.text.AbstractDocument.insertString(AbstractDocument.java(Compiled Code))
at javax.swing.text.PlainDocument.insertString(PlainDocument.java(Compiled Code))
at javax.swing.text.DefaultEditorKit.read(DefaultEditorKit.java(Compiled Code))
at javax.swing.text.JTextComponent.read(JTextComponent.java:1350)
at MyThread.readin(MyThread.java:81)
at MyThread.run(MyThread.java:115)

The testcase listens for WindowClosing event.  When the window is closed, the instance of JTextArea, JFrame and all the panels are nullified.  This should cause the old instances of JTextArea and array that is used to store the data, which is internally created in GapContent class should get cleared and the memory occupied by the array should be released back.  However, this does not seem to be happening, which causes the memory to be accumulated and eventually leading to OOM.

Comments
EVALUATION DefaultCaret registers itself with a Timer thread. When the frame that contains the text area is closed, the timer thread remains alive and keeps a string of references to the text area, such as below: Timer timer references EventListenerList listenerList references Object[] listenerList contains DefaultCaret$Handler references outer class BasicTextUI$BasicCaret references JTextArea component This problem seems to be common to all JTextComponents.
23-05-2008