JDK-6546068 : system hangs when calling TrayIcon.setToolTip in shutdown hook
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-04-13
  • Updated: 2010-04-04
  • Resolved: 2007-04-17
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Windows XP Professional service pack 2

A DESCRIPTION OF THE PROBLEM :
System hangs when trying to change tooltip or image for TrayIcon in shutdown hook.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile class I submitted, run it and press Ctrl+C or just close the console window to initiate shutdown hook method

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Two strings should apear on console and program should exit:
Setting tooltip
  Tooltip set successfully
Or just first string and exception about not available tray icon
ACTUAL -
Tray icon disappears just after shutdown started, before first string "Setting tooltip" appears. After that system hangs and can be only terminated from Task Manager or "End Program" dialog

ERROR MESSAGES/STACK TRACES THAT OCCUR :
There is not any error messages

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.SystemTray;
import java.awt.Toolkit;
import java.awt.TrayIcon;


public class TestTray implements Runnable {
    private static TrayIcon trayIcon;

    public static void main(String[] args) throws Exception {
        SystemTray tray = SystemTray.getSystemTray();
        
        trayIcon = new TrayIcon(Toolkit.getDefaultToolkit().createImage("trayicon.gif"));
        tray.add(trayIcon);
        Thread hookThread = new Thread(new TestTray());
        Runtime.getRuntime().addShutdownHook(hookThread);
        for (;;) {
            Thread.sleep(1000);
        }
    }
    
    public void run() {
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
        }
        System.out.println("Setting tooltip");
        trayIcon.setToolTip("Stopping"); //hangs here, same with setImage method
        System.out.println("Tooltip set successfully");
        try {
            Thread.sleep(20000);
        } catch (InterruptedException e) {
        }
    }
}

---------- END SOURCE ----------

Comments
EVALUATION rfe #6301682 is about similar problem, so if someone wants to have suggested functionality, he/she should vote for that rfe. This particular CR I'm closing as not a bug because of the facts mentioned in the evaluation earlier.
17-04-2007

EVALUATION I have tried to workaround this problem: inserted an addition check to the WTrayIconPeer.setToolTip() method, is toolkit is alive or not. If not, the corresponding native method is not called. This works, the test exits successfully. However, as I mentioned earlier, the same problem can be reproduced with *any* native call to awt.dll, so to completely fix the problem we need to insert this check before any native call. I doubt this is worth doing: see my first comment about the JavaDoc for addShutdownHook.
17-04-2007

EVALUATION I have attached the full thread dump at the moment of hang. It is clearly seen that the 'problem' method is WTrayIconPeer.setTooltip(), however this method is actually not called. It looks like the awt.dll library has been already unloaded and JVM can't call the native method.
17-04-2007

EVALUATION I'm able to reproduce the hang easily. Moreover, I have noticed that any AWT call that uses the native code also lead to the hang (for example, new Frame().pack()). From the other side, I have found the following statements in the JavaDoc for addShutdownHook() method: Attempts to use other thread-based services such as the AWT event-dispatch thread, for example, may lead to deadlocks. or It is therefore inadvisable to attempt any user interaction or to perform a long-running computation in a shutdown hook. So it seems that the test is not correct from the JVM's point of view.
17-04-2007