SUMMARY: Java VM hangs in AbstractButton.getDisabledIcon

    DETAILED DESCRIPTION: follows...
There is a VERY serious bug in Sun's JDK involving the use of buttons that have disabled images. The bug
results in the entire JVM hanging, requiring that the application be killed externally. This bug is
reproducable on Win/NT4 SP4 and Solaris 7. It only appears to be a problem when the OS is configured to use multiple CPUs, which is a fairly common configuration here at Mentor.

There is a separate bug report in the JDC bug parade, with the number 4327282.

The testcase that I've included down below very reliably reproduces the bug, although it should be noted
that the bug does not occur %100 of the time. On the NT systems(note I've seen this is a variety of NT boxes)
I've used it seems to be easier to get the bug to appear(in one test it happened 5/5) than on Solaris(although I reproduced it on two different Solaris machines just a little while ago). I would say that if the testcase is run 10 times you're sure to see the problem.

On NT I get the following stack trace by hitting Control-C in the shell the testcase is invoked from:

"AWT-EventQueue-0" prio=7 tid=0x784e10 nid=0xb0 waiting on monitor [0x93df000..0x93dfdc8]
?at java.lang.Object.wait(Native Method)
?at java.awt.MediaTracker.waitForID(MediaTracker.java:632)
?at javax.swing.ImageIcon.loadImage(ImageIcon.java:226)
?at javax.swing.ImageIcon.<init>(ImageIcon.java:161)
?at javax.swing.AbstractButton.getDisabledIcon(AbstractButton.java:542)
?att javax.swing.plaf.basic.BasicMenuItemUI.paintMenuItem(BasicMenuItemUI.java:561)
?att javax.swing.plaf.basic.BasicMenuItemUI.paint(BasicMenuItemUI.java:473)
?att javax.swing.plaf.basic.BasicMenuItemUI.update(BasicMenuItemUI.java:469)
?at javax.swing.JComponent.paintComponent(JComponent.java:398)

I also have a truss output if interested.

To run the testcase, compile the code below, then invoke. After the window appears click on the "Test"
menubar button. If the menu pops down the the bug didn't occur so exit and try again. If the menu doesn't
pop down then BINGO! you've just seen the hang. You'll have to kill the VM process manually to get it to quit.

Note that if you invoke the testcase with a command-line argument the images in the menu will not be disabled.
This allows you to run the testcase and not have to worry about the bug because the images in the menu won't
be disabled.


Here's the source code for the testcase:

---------------------
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

public class DisabledImageHang extends JFrame {
// ###
// ### UPDATE THE FOLLOWING PATH FOR YOUR SYSTEM
// ###
static final String IMAGES = "d:/jdk1.3rc2/demo/jfc/Notepad/resources/";
static final String[] NAMES =
{"cut.gif","copy.gif","paste.gif","open.gif","save.gif"};

public DisabledImageHang(boolean disable) {
JMenuBar menuBar;
JMenu menu;
JMenuItem menuItem;

addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent e) {
System.exit(0);
}
});

menuBar = new JMenuBar();
setJMenuBar(menuBar);

menu = new JMenu("Test");
menu.setMnemonic('T');
menuBar.add(menu);

for (int i=0; i<NAMES.length; i++) {
menuItem = new JMenuItem("New Item #"+i);
menuItem.setIcon(new ImageIcon(IMAGES + "/" + NAMES[i]));
if (disable)
menuItem.setEnabled(false);
menu.add(menuItem);
}
}

public static void main(String[] args) {
DisabledImageHang window = new
DisabledImageHang((args.length == 0));

window.setTitle("Popup w/ Disabled Icons Bug");

window.setBounds(300, 300, 400, 400);
window.setVisible(true);
}
}


> 1. Which version of 1.2 have you duplicated this problem with?
> do: java -fullversion

on NT ==> java full version "JDK-1.2.2-001"

I tried duplicating it on a multi-processor Solaris box using the
following 1.2.2 production version but I couldn't see the
problem(although I did see it when I ran 1.3ra on the same system):

  java version "1.2.2"
  Solaris VM (build Solaris_JDK_1.2.2_05a, native threads, sunwjit)

The system I used was "hawk" in the lab, an U80 running Sol 7.

The notable difference here is that using 1.3 may be using green threads
instead of native, and we see the problem on hawk using 1.3.


> (Have you seen this with reference and production?)

This is confusing, but I think we have just used reference bits. However
you can run the testcase and see.



>
> 2. Where was the program compiled? Where was the application run?
> <give all scenarios>

Compiled and run on //orw-jvella, a dual-processor NT4 SP4 Compaq
system.

I've also run it on my home HP Kayak system using various 1.3 releases
and seen the "hang" problem MANY different times. The Kayak is a
dual-processor system with NT4 SP4 installed.

Compiled and run on a E450 running Solaris 7.

>
> 3. Does this happen on a single processor machines at all?
>

No.