Bug ID: JDK-4789067 Debugging test JUnit classes locks up IDE

Type: Bug
Component: client-libs
Sub-Component: 2d
Affected Version: 1.4.0,1.4.1,1.4.1_01

Priority: P2
Status: Resolved
Resolution: Fixed
OS: solaris_2.5,windows_2000
CPU: x86

Submitted: 2002-12-05
Updated: 2003-02-26
Resolved: 2003-02-03

Other	Other
1.4.1_03 03Fixed	1.4.2Fixed

Win 2000 SP2, JDK 1.4.1_01, S1S4u1 EE (also happens in
netBeans)

IDE either fails with assertion exception (and locks-up)
or simply locks-up.
1) Follow http://junit.netbeans.org/JUnit_tutorial.html
2) Open any of the ...Test classes
3) Create breakpoint
4) Debug root test class.
Voila!

Assertion exception is NOT written into ide.log and looks 
like this:

"...
Time: 0.078
There was 1 failure:
1)testGreeting2(HelloWorldTest)
junit.framework.AssertioFailedException: expected:<Hello 
world!> but was:<Good bye>
	at HelloWorldTest.testGreeting2
(HelloWorldTest.java:46)
	at sun.reflect.NativeMethodAccessorImpl.invoke0
(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegationMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
	at org.netbeans.junit.NbTestCase.run
(NbTestCase.java:76)
	at RootSuite.main(RootSuite.java:22)

FAILURES!!!
Tests run: 3,  Failures: 1,  Errors: 0"

IDE is responsive ~0.5 seconds after the execption appears, then locks up.
For JVM stacktrace see attachment.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.1_03 mantis-beta tiger FIXED IN: 1.4.1_03 mantis-beta tiger INTEGRATED IN: 1.4.1_03 mantis-b16 mantis-beta tiger tiger-b05
27-08-2004
WORK AROUND ###@###.### 2002-12-12 BTW, this problem does not happen when using jdk 1.4.0_02 (instead of jdk 1.4.1_01) on Windows 2000 platform. Problem also does not happen on Solaris 8 system using either jdk 1.4.1_01 or jdk 1.4.0_02.
27-08-2004
SUGGESTED FIX The updated version of the fix, reviewed by the engineering team: http://javaweb.sfbay/~tdv/bugs/4789067/fix2 or: * /tmp/geta28087 Wed Jan 15 13:52:27 2003 --- ImageFetcher.java Wed Jan 15 13:36:29 2003 *********** * 157,164 **** private void fetchloop() { Thread me = Thread.currentThread(); while (isFetcher(me)) { ! if (Thread.interrupted()) ! return; // Bail if interrupted me.setPriority(HIGH_PRIORITY); ImageFetchable src = nextImage(); if (src == null) { --- 157,168 ---- private void fetchloop() { Thread me = Thread.currentThread(); while (isFetcher(me)) { ! // we're ignoring the return value and just clearing ! // the interrupted flag, instead of bailing out if ! // the fetcher was interrupted, as we used to, ! // because there may be other images waiting ! // to be fetched (see 4789067) ! me.interrupted(); me.setPriority(HIGH_PRIORITY); ImageFetchable src = nextImage(); if (src == null) { ###@###.### 2003-01-14
14-01-2003
EVALUATION Karthik (12/16/2002): This seems to be a bug in jdk1.4.1/windows. Transferring to java category. =============================================================================== I don't see any deadlock in the thread dump. Apparently this bug was reassigned to AWT because ###@###.### saw that there is no mention of any JPDA class or threads in the thread dump. However, he thought there might be some problem with MediaTracker. I doubt that assessment is correct: neither MediaTracker nor ImageIcon has had any changes (other than docs) since Merlin. ###@###.### also commented that the thread dump doesn't show any ImageFetcher threads. Usually the ImageIcon deadlocks involve one of those. So, there is no obvious cause. Somebody just needs to start debugging to see where the problem might be (e.g. the VM, device driver, or some other area). ###@###.### 2002-12-17 Name: osR10079 Date: 12/19/2002 I have reproduced this problem not only on Win2K, but on WinNT, too. I was using NetBeans 3.3.2. Hang happens at the attempt to create ImageIcon which tries to load some image. This does not depend on which specific image it tries to load, as I could reproduce similar hang (also when loading images for ImageIcon) in different places, and sources of images were different (once I saw that it hung while creating an image from byte array). The problem is related to the fact that ImageIcon calls MediaTracker.waitForID() with zero timeout. As a result, MediaTracker waits forever, because the image, for some reasons, is considered not loaded. I verified that it is not a problem of missing notify() call: I changed the code to check status of loading periodically, and the status showed that image loading wasn't complete. In other words, this happens not because notify() happens before corresponding wait(), but because notify() doesn't happen at all. ###@###.### 2002-12-19 ====================================================================== Evaluation form ###@###.### During investigation of this bug i found that the cause of the problem is that we are unable to load some next to be loaded image. This happens with different images, the amount of images loaded successfully before it varies. I've updated bug-report with results of my investigation. Since the image-loading functionality of MediaTracker belongs to 2D, I am reassigning to that group. See also 4332685, 4335416, etc. Those were fixed earlier (e.g. Merlin), so perhaps there was a regression in Hopper? ###@###.### 2002-12-19 Since the nature of the bugs with MediaTracker is usually some kind of multithreading issue, it's possible that the bug surfaced because of some timing changes due to vm or some other changes. I don't believe, though, that this bug meets a mantis showstopper criteria, so the fix most likely won't make it into mantis. If the customer needs the fix, the bug should be escalated. ###@###.### 2003-01-02 Note that I can't get to reproduce the bug on NetBeans 3.4, although it readily manifests with S1SU4 on the same jre (1.4.2). ###@###.### 2003-01-09 The SunOneStudio can be hung even w/o debugging w/ JUnit, by just playing with the menus: bring up any menu, and then move the mouse over the menubar causing other menus to open following the pointer. Eventually the ide would hang. Can't reproduce this behavior with NetBeans 3.4. Another observation: NetBeans 3.4 use only ImageIcon objects (and, thus, a single ImageTracker instance) to load all it's images, while Sun1Studio (and, presumably, previous versions of NetBeans) utilizes more than one ImageTracker (they're using ImageIcons and, at least another one in org.openide.utils.actions.SystemAction.FixedAction.paintIcon()). So one guess would be that multiple ImageTrackers somehow affect each other (as they share ImageFetcher threads), possibly by killing the ImageFetcher which is loading an image for another ImageTracker, causing the latter to wait for COMPLETE notification indefinitely. Continuing investigation. ###@###.### 2003-01-09 Here's what's going on. Each application context can have no more than 4 ImageFetchers. When all of them are busy fetching the images, the new sources are being put into a queue. When a fetcher is done with its current source, it checks if there's another one waiting to be fetched, takes it off the queue and proceeds fetching. If the queue is empty, the Fetcher thread exits. The problem is that if the fetcher is interrupted, it quits w/o checking if there's something in the queue to fetch (see ImageFetcher.fetchloop()). So we end up with images waiting to be fetched but no ImageFetcher threads, because we add can create them only when we add a new fetchable (ImageFetcher.add()). The fetcher can be interrupted, for example, when ImageWatcher becomes uninterested in the image (ImageWathed.newInfo()), i.e, when imageUpdate returns false, which some of the classes in SunOne studio code do: org.openide.awt.ToolbarToggleButton, for example, returns false from imageUpdate, presumably when the button in question becomes invisible or something. Note that the NetBeans 3.4 use only ImageIcon class to fetch the images, which doesn't interrupt reading until it's done - this can explain why NetBeans 3.4 do not exhibit the problem. One possible fix would be to check if the waiting queue is empty prior to exiting the ImageFetcher thread in the ImageFetcher.fetchloop(). Actually, it doesn't seem that we even need to check if the thread was interrupted in this case. But I'll need to double-check on that - we may at least need to clear the interrupted status of the thread by calling Thread.interrupted(). The changes in the suggested fix section proved to fix the problem for SunOne studio. ###@###.### 2003-01-14 Please note that the fix suggested above has not been revewed/approved by the engineering team yet. ###@###.### 2003-01-14 As per the review comments, I've updated the suggested fix to clear the interrupt state of the ImageFetcher thread. ###@###.### 2003-01-15
14-01-2003

Duplicate :	JDK-4699667 - MediaTracker.waitForID hangs (dual-processor box)
Duplicate :	JDK-4809173 - java.awt.MediaTracker.waitForID() never returns