Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4473013

Merlin: memory leak from the use of JColorChooser

    XMLWordPrintable

    Details

    • Subcomponent:
    • CPU:
      x86
    • OS:
      windows_2000

      Description


      ingrid.yao@Eng 2001-06-21

      J2SE Version (please include all output from java -version flag):
        java version "1.4.0-beta"
        Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b65)
        Java HotSpot(TM) Client VM (build 1.4.0-beta-b65, mixed mode)

      Does this problem occur on J2SE 1.3? Yes / No (pick one)
        Not as serious as Merlin. For 100 iteratoins, it consumed
        ~23520K memory usage, but used ~78572K memory usage for
        only 92 iterations on 1.4.

      Operating System Configuration Information (be specific):
        NT 4.0 SP6

      Hardware Configuration Information (be specific):
        IBM Thinpad 600E 192 MB RAM 400 MHZ 20 GB HD

      Bug Description:
      ++++++++++++++++++
      Attached is a stand-alone Swing application(ColorChooserBug.java) - which
      demonstrates a memory leak which seems to stem from our use of JColorChooser.

      The application is somewhat complex, because it seemed that removing
      any of the complexity (eg. Listener member variables) removed the leak
      as well. The structure of the application is as follows:

      The main panel essentially has two separate instances of ColoredButtons.
      Each ColoredButton has it's own instance of ColorPopupMenu. When each
      ColorPopupMenu is instantiated, a new JColorChooser is instantiated,
      it's ColorChooserPanels are are re-ordered, and the JColorChooser is
      added to the popup menu. (Note that these ColorPopupMenus need NOT
      be displayed to observe the leak.)

      The application accepts a single command-line argument which is the
      number of times a new JDialog (with the afore-mentioned panel as it's
      content) will be created, made visible, hidden, and disposed of. On
      my machine, running this application with a value of 50 on the command
      line resulted in about 13Mb more memory being consumed than when run
      with a value of 1.

      When a similar dialog is deployed within a more complex Swing application,
      the memory leak is much more drastic, and OutOfMemoryErrors will eventually
      occur.


      Steps to Reproduce (be specific):
      ++++++++++++++++++++++++++++++++++
      Run sample program, try 100 iterations

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              rraysunw Richard Ray (Inactive)
              Reporter:
              tyao Ting-Yun Ingrid Yao (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: