Created attachment 24964 [details]
Thread dump

Jirka,
this could be yours, please look at it.

Not Jirka's.

Yarda do you know what is wrong here? I am not sure what lookup expects locking
order to be.

*** Issue 63482 has been marked as a duplicate of this issue. ***

Please, could you look at it in near future? It blocks commit validation often.
Sometimes even report is not sent to broken_builds but process is quietly killed
(e.g. 09:19 09/22/2005). I can easily reproduce it manually on Windows (repeat
to disable/enable image module). Thanks.

David, this is your deadlock due to lookup of ModuleFactory... 

If it is due to my commit I will try to fix it. If I am not able to do so I will
reassign back to you.

Checking in ProxyClassLoader.java;
/cvs/core/bootstrap/src/org/netbeans/ProxyClassLoader.java,v  <-- 
ProxyClassLoader.java
new revision: 1.21; previous revision: 1.20
done

Please verify.

BTW this call is also *very* suspicious:
org.openide.modules.InstalledFileLocator.getInstances(InstalledFileLocator.java:194)
Calling allInstances from withing a private lock is begging for problems. I
suggest to patch also InstalledFileLocator to call this without holding a lock
(and potentially lock only assigning the result if needs to be). It is generally
 much safer to call allInstances twice and synchronizde only assigning the
result ...

I will patch InstalledFileLocator.java acc. to David's comments (thanks for tip!).

It seems that the commit validation on the continuous build of release50_beta
failed for the same reason. A beta fix candidate?

I am not sure it could affect the users. I can't reproduce it by hand.

BTW: we have to fix it if it causes failing of commit validation, just to be
sure it won't happen during building of Beta.

So, 
David is it safe? 

Jirka, 
can you reproduce it manually? Is it reproducible only on Sol/SPARC?

FYI:

committed     Up-To-Date  1.2        
openide/modules/src/org/openide/modules/InstalledFileLocator.java

Re "Is it reproducible only on Sol/SPARC?"

Commit validation locked for me on Windows at the same point the day before
yesterday. I suspect it was the same problem. I don't think it's Sol/SPARC specific.

Ok, lets say this is beta stopper. 

David, or anybody from the core team, 
please prepare the patch for today's trunk build (we need to test it before
merge to beta branch).

Jirka , 
could you please verified in trunk (or continual build) ?

Thanks in advance.

Marian sorry but I don't know what do you mean by "prepare the patch for today's
trunk build". The change is in the trunk since yesterday evening ...

To Honza: I assume the fix being pretty safe. It calls much less code under the
lock. The methods that are now called unsynchronized operate only on local data
so the risk of data corruption is IMHO very low (only if I overlooked
something). I suggest Jarda reviews the change before you commit it to the beta
branch.

David:
You are right, the fix is there, but I think it can't be in the yesterday's
build (it was built after the fix was integrated, I think).
Don't worry, we can verify the fix in continual build, I hope ;)

I do not understand how you can believe fixing deadlocks without a test is 
useful... 
 
core/bootstrap/test/unit/src/org/netbeans/Deadlock64710Test.java,v  <--  
Deadlock64710Test.java 
initial revision: 1.1 
 
I had this ready for commit yesterday evening, but the CVS was locked by 
httpd... 

Commit validation on release50_beta deadlocked again. We should have put the fix
into the branch. Too late now, I'm afraid. :-(

Well, does it mean : this isn't fixed in Beta branch ?

Sounds like it. You want a re-spin of the Beta bits?

Ok, we know this can occur during commit validation. Has anybody seen a user
report of this deadlock?

Ok, we know this can occur during commit validation. Has anybody seen a user
report of this deadlock?

It hasn't been reported by real-user so far, so propose to let it fixed just in
trunk (not for Beta).