Created attachment 8725 [details]
Thread dump

I suggest just to remove the synchronized keyword from the mentioned
method. If two threads would try to call it simultaneously random one
would succeed. The same is without the synchronized. So - I don't
understand what does it do.

I cannot even start IDE on JDK 1.4.1 on W2K (tried dev builds 20030129
and 20030128). Comes up only for the first time (no user dir).

Can't reproduce any problem myself, so I will just have to take your
(tpavek, mslama) word for it. Don't think I changed anything important
recently.

dstrupl: You cannot simply un-synchronize resultChanged, as it might
then set a new instance of handlers while some other thread is calling
createURLStreamHandler, causing array index out of bounds exceptions
etc. The synchronization protects access to this data.

However I can try moving allInstances() out of the synch block, and
synchronize only on actual accesses to the handlers instance field. I
don't think there is any particular reason to synch access to the
lookup result, since it will only be used when firing changes, which
is already synchronized by the lookup impl.

Note that the deeper causes of the deadlock are the usual suspects:

1. Cyclic dependencies in core infrastructure. The folder recognizer
is loading stuff from Services/ for FolderInstance, trying to find a
URL handler. Some of the layer files are using some protocol (nbres:
perhaps?) which is defined as a service in lookup. Therefore to look
for such a URL handler involves invoking URL handlers. In my
terminology from nbdev yesterday, the URL handlers should be split
into basic handlers (nbfs: and nbres: count) which are hardcoded (~
Stratum 0 I guess you could say) and may be used in Stratum 1, incl.
when defining new URL handlers; and secondary ones (e.g. nbdocs:)
needed only for Stratum 2 files (e.g. help sets).

2. Pointless multithreading. Main thread is doing some work, starting
up, then it suddenly blocks on folder recognizer for a while, then
(normally) continues. If everything were all in one thread, there
would be no deadlock here. (Nested calls might pose a problem for
other reasons, but at least they would not deadlock, and it would be
much more likely to be reproducible and easily testable/fixable.)

committed     Up-To-Date  1.5        
core/src/org/netbeans/core/NbURLStreamHandlerFactory.java

Somebody please verify. I confirmed that *I* did not get deadlocks and
that unit tests pass. But I never saw the deadlock so I have no way of
knowing if I really fixed it.

Could not reproduce it in 20030130, looks ok.