|
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 xxxxx@xxxxx 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.
xxxxx@xxxxx 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).
xxxxx@xxxxx 2002-12-17
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.
xxxxx@xxxxx 2002-12-19
======================================================================
Evaluation form xxxxx@xxxxx
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?
xxxxx@xxxxx 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.
xxxxx@xxxxx 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).
xxxxx@xxxxx 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.
xxxxx@xxxxx 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.
xxxxx@xxxxx 2003-01-14
Please note that the fix suggested above has not been revewed/approved
by the engineering team yet.
xxxxx@xxxxx 2003-01-14
As per the review comments, I've updated the suggested fix to clear the
interrupt state of the ImageFetcher thread.
xxxxx@xxxxx 2003-01-15
|
