Bug 50829 - Deadlock when using CVS add action (in explorer)
Deadlock when using CVS add action (in explorer)
Product: projects
Classification: Unclassified
Component: Generic Infrastructure
PC Windows ME/2000
: P2 (vote)
: 4.x
Assigned To: Jesse Glick
Depends on:
  Show dependency treegraph
Reported: 2004-10-25 22:42 UTC by Peter Zavadsky
Modified: 2004-10-27 19:51 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT

Full thread dump when deadlocked (15.36 KB, text/plain)
2004-10-25 22:48 UTC, Peter Zavadsky
another deadlock on beta2 (11.25 KB, text/plain)
2004-10-25 23:10 UTC, Peter Zavadsky

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Zavadsky 2004-10-25 22:42:35 UTC
Build 200409220845

Just adding several sources in a row using CVS Add
action (from explorer popup), leads to deadlock
fairly often on my machine.

Attaching full thread dump.
Comment 1 Peter Zavadsky 2004-10-25 22:48:57 UTC
Created attachment 18502 [details]
Full thread dump when deadlocked
Comment 2 Peter Zavadsky 2004-10-25 23:10:26 UTC
Created attachment 18503 [details]
another deadlock on beta2
Comment 3 Peter Zavadsky 2004-10-25 23:11:47 UTC
4.0 beta2

There is also another one which looks same, happened on beta2 (see the
above attachment), now I am not sure if it has to do with vcs impl or
project api, please evaluate, and assign accordingly.
Comment 4 Martin Entlicher 2004-10-26 10:06:22 UTC
Looks more like a projects issue. Two threads are waiting on
dir2Proj.wait(); but it seems to be never notified...
Comment 5 Jesse Glick 2004-10-26 20:50:11 UTC
No idea how to reproduce; never happened to me. Also you are using
beta 2; many things have changed since then in dev builds.

I did some analysis of ProjectManager.loadProject and determined that
it is possible to get a starved thread (producing a thread dump
similar to the ones you attach), but only if thread #1 starts to load
a project, then thread #2 asks for the same project but waits for #1
to get it first, then thread #1 throws an exception rather than
returning a valid result; in that case #2 will wait forever for a
result which is not coming. Reproduced this in a unit test and wrote a
fix for it. However this is probably a very rare situation, and from
your description of your problem, it is probably not what is happening
to you.

I did add some logging code to ProjectManager so you can run with


to get a pretty detailed log of what it is doing during project loads.
If you can reproduce in a dev build with this trace information on, by
all means reopen with your log file.
Comment 6 Jesse Glick 2004-10-27 19:51:17 UTC
Fix for the problem I did find, and logging:

committed   * Up-To-Date  1.7        
committed   * Up-To-Date  1.6        
committed   * Up-To-Date  1.10       
committed   * Up-To-Date  1.7        
committed   * Up-To-Date  1.8        

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo