Disposing JDialog increases CPU usage up to 100%

[Andreas Pax Lück]

Hi Java friends.

I'm confronted with a really strange issue. I cannot reproduce the problem in another case, but only in this single case. Perhaps, you did already gather some experiences with this:

I'm showing a modal JDialog in a main frame context. The default close operation was set on DISPOSE_ON_CLOSE. As soon as I close the JDialog its dispose method is invoked continuously all the time. It never ends and the CPU usage increase on 100%.

I checked similiar JDialogs of my application but the strange behaviour doesn't occur. The main frame which creates the JDialog instance doesn't store any reference to it and the JDialog doesn't execute any further threads.

I have no idea what's going wrong. Is it a JVM bug? Or is there's something wrong with my implementation?

Best regards



Uncle PAX

/**
 * Assistant for file transmission to the remote machine.
 * 
 * @author PAX
 */
public class FileTransmissionDialog extends JDialog implements FileTransmissionDisplayable
{
    /**
     * @author PAX
     */
    private static final long serialVersionUID = 2628102449528570009L;
    
    /**
     * Reference to the main frame.
     * 
     * @author PAX
     */
    private MainFrame parent;
    
    /**
     * Open file dialog.
     * 
     * @author PAX
     */
    private JFileChooser chooser;
    
    /**
     * Responsible for file transmissions.
     * 
     * @author PAX
     */
    private FileBroadcaster fileBroadcasterThread;
    
    @Override
    public void setVisible(boolean isVisible)
    {
        if (this.parent != null)
        {
            FrameUpdateMgr fut = this.parent.getFrameUpdateMgr();
            if (fut != null)
            {
                if (isVisible)
                {
                    fut.pause();
                    System.out.println("Continuously frame requestion paused.");
                }
                else
                {
                    fut.restart();
                    this.parent = null;
                    System.out.println("Continuously frame requestion resumed.");
                }
            }
        }
        
        super.setVisible(isVisible);
    }
    
    @Override
    public void dispose()
    {
        if (this.parent != null)
        {
            FrameUpdateMgr fut = this.parent.getFrameUpdateMgr();
            if (fut != null)
            {
//                fut.restart();
//                this.parent = null; TODO
                System.out.println("Continuously frame requestion resumed.");
            }
        }
        
        super.dispose();
    }
}

This is a piece of the source code. The file transmission thread isn't active when the JDialog becomes disposed. But the AWT event dispatching thread calls the dispose method immediatly without blocking the AWT queue.

[Andreas Pax Lück]

The JDialog's further highlights:

uses CardLayout

shows an animated GIF file with animation loop

contains a JTable with an own cell renderer (nothing special)

[Darryl Burke]

Andreas Pax Lück wrote:

shows an animated GIF file with animation loop

Clarify 'animation loop'

Your problem may be in the nature of this fixed bug
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4302818

[Andreas Pax Lück]

It's an endless GIF animation. But even if I remove this GIF image from the dialog this bug occurs.

I was running Java 1.6_18 and now I tried 1.6_21. No success.

[Ernest Friedman-Hill]

Put something like this in dispose():

new Exception().printStackTrace();

and then copy and paste us one of the stack traces -- it will let us know what is invoking dispose(). There may be a loop among several methods, and it might make sense in looking at the trace.

[Andreas Pax Lück]

This equals all the time:

java.lang.Exception
at client.gui.FileTransmissionDialog.dispose(FileTransmissionDialog.java:305)
at client.gui.FileTransmissionDialog.cancelButtonActionPerformed(FileTransmissionDialog.java:382)
at client.gui.FileTransmissionDialog.thisWindowClosed(FileTransmissionDialog.java:539)
at client.gui.FileTransmissionDialog.access$6(FileTransmissionDialog.java:537)
at client.gui.FileTransmissionDialog$7.windowClosed(FileTransmissionDialog.java:598)
at java.awt.Window.processWindowEvent(Unknown Source)
at javax.swing.JDialog.processWindowEvent(Unknown Source)
at java.awt.Window.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

[Andreas Pax Lück]

Thanks, my friends. Now, I found the really stupid bug in my code.

Take a look at the stack trace: It's eye-catching that the handler method of the windows closed event invokes the handler method of the cancel button which triggers dispose. Usually, it cannot be possible that this is repeated all the time.

But obviously, I created a loop with help of the windows closed handler. Following important (forgotten) method from the piece of code above creates this loop:

    /**
     * Cancel button pressed.
     * 
     * @param e
     * 
     * @author PAX
     */
    private void cancelButtonActionPerformed(ActionEvent e) 
    {
        if (this.fileBroadcasterThread != null)
            this.fileBroadcasterThread.interrupt();
        
        this.dispose();
    }

    private void thisWindowClosed(WindowEvent e) 
    {
        this.cancelButtonActionPerformed(new ActionEvent(e, ActionEvent.ACTION_PERFORMED, "window was closed" + e.getID()));
    }

Thanks for all your help. You showed me the possible area of the bug.

Best regards


Uncle PAX