Created attachment 52296 [details]
thread dumps

The deadlock doesn't occur for every startup, even for the same IDE state at shutdown.

I'm not really sure what is wrong. IMO the potential of deadlock in a situation like this has there been since 18 Nov
2003 when TabbedAdapter was changed to fire its state changed under AWTTreeLock. The deadlock is between AWT thread
which holds AWTTreeLock and tries to create a JsfTopComponent, which in turn tries to load its toolbar and ends up
waiting for FolderInstance RP thread. The FolderInstance is at the same time trying to load AnnotationTypes that for
some reason create JSeparator, which as a swing component needs AWTTreeLock, ending up in deadlock.

I'm reassigning this to core/windows for their evaluation. Hopefully somebody will come up with some clever idea how to
prevent this situation. Thanks

TabbedAdapter is part of winsys and winsys strictly operates through EQ thread with its clients, similarly like Swing.
So TabbedAdapter firing in EQ seems okay to me from winsys point of view.

IMHO, loading AnnotationTypes shouldn't wait for AWT lock, that seems bad to me. But how to achieve that? I don't know.

Another possibility would be for visualweb/jsf to not wait on toolbar to get loaded, but attach some listener when
loading is finished (if that's possible, I don't know).

Passing to visualweb, ccing AnnotationTypes authors and thread experts.

Just for the record, the problem is not that TabbedAdapter fires on EQ, but that it fires when holding AWTTreeLock. As a
general rule of thumb events should never be fired when holding locks. Nobody knows who can listen and what other locks
they may need to acquire. At the same time I understands that the locking in TabbedAdapter was done to prevent extensive
repaints and it's been in place for ages, so it's really hard to blame.

#1 TabbedAdaptor is OK to fire changes in AWT event thread
#2 TabbedAdaptor is wrong to fire changes while holding AWT tree lock

In general it is recommened to never deliver any events to listeners while holding a lock. Listeners are foreign and 
unknown code and as such subject to deadlock. That is why I think that this deadlock is TabbedAdaptor fault at

        at org.netbeans.core.windows.view.ui.tabcontrol.TabbedAdapter.fireStateChanged(TabbedAdapter.java:441)
        - locked <0x08abce90> (a java.awt.Component$AWTTreeLock)

However I inspected the source code, and there is a note about "holding of AWT tree lock" speeding up some redrawing. 
Looks like we will have to choose between speed and deadlocks (or correctness).

OK, thanks for an explanation, passing back to me. I'll remove tree lock, hang is more serious then redrawing speed and
moreover in JDK 1.6 and further it may not be valid, or at least we don't have the speedup measured and confirmed AFAIK.
If redrawing speed turns to be a problem, we should consider another techniques to speed it up.

tree lock removed:

Checking in TabbedAdapter.java;
/cvs/core/windows/src/org/netbeans/core/windows/view/ui/tabcontrol/TabbedAdapter.java,v  <--  TabbedAdapter.java
new revision: 1.41; previous revision: 1.40
done

I tested both on Linux and Win, under JDK 1.5 and 1.6 and I couldn't reproduce multiple redrawing when tree lock was
removed, even with J-Dawt.nativeDoubleBuffering=true set. Either is redrawing fixed in newer JDKs or impact is so low
that it's not visible anymore.

Could probably also have been fixed in visualweb, though it is hard to say what other code might have been affected.
Root problem to me looks like creation of JSeparator in FolderInstance which grabs AWT lock.

verified in:

Product Version: NetBeans IDE 6.0 RC2 (Build 200711201000)
Java: 1.6.0_03; Java HotSpot(TM) Client VM 1.6.0_03-b05
System: Linux version 2.6.22-14-generic running on i386; UTF-8; en_US (nb)
Userdir: /home/petr/.netbeans/6.0rc2