Bug 114552 - Deadlock in ProjectManager
Deadlock in ProjectManager
Status: RESOLVED FIXED
Product: projects
Classification: Unclassified
Component: Generic Infrastructure
6.x
All All
: P1 (vote)
: 6.x
Assigned To: Milos Kleint
issues@projects
beta1fix
: RANDOM, THREAD
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-03 19:24 UTC by Martin Krauskopf
Modified: 2007-09-07 09:05 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
deadlock.txt (19.68 KB, text/plain)
2007-09-03 19:25 UTC, Martin Krauskopf
Details
deadlock.txt with read access (23.97 KB, text/plain)
2007-09-06 08:43 UTC, Martin Krauskopf
Details
second patch (3.13 KB, patch)
2007-09-06 13:33 UTC, Milos Kleint
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Krauskopf 2007-09-03 19:24:27 UTC
See the attached thread dump. The "wizard-descriptor-asynchronous-jobs" waits - dir2Proj.wait(); while holding write
access to ProjectManager's mutex. But notification is not reached - nobody can reach the dir2Proj.notifyAll() since
ProjectManager's mutex is needed, but is held (in write access) by the waiting thread (??)
Not sure what role has "Versioning" thread which is also trying to gain ProjectManager's mutex. I supposed it's OK to
call VisibilityQuery from within ProjectManager's write access.... actually now I see there, in the ProjectManager, code:

  if (Thread.currentThread() == loadingThread) {
      throw new IllegalStateException("Attempt to call ProjectManager.findProject within the body of \
          ProjectFactory.loadProject (hint: try using ProjectManager.mutex().postWriteRequest(...) \
          within the body of your Project's constructor to prevent this)"); // NOI18N
  }

but it was not thrown...
Comment 1 Martin Krauskopf 2007-09-03 19:25:21 UTC
Created attachment 48000 [details]
deadlock.txt
Comment 2 Milos Kleint 2007-09-04 09:52:47 UTC
done. The problem was:
When Thread1 started loading projectA, it sets the loadingThread variable to Thread1.
Any thread attempting to load projectA now stops and waits for the load to finish.
However if Thread2 attempts to read projectB now, it resets loadingThread to Thread2 and if that happens before Thread1
gets into the wrong code that calls findProject(), the exception is not thrown and the Thread1 deadlocks.

Checking in ProjectManager.java;
/cvs/projects/projectapi/src/org/netbeans/api/project/ProjectManager.java,v  <--  ProjectManager.java
new revision: 1.34; previous revision: 1.33
Comment 3 Milos Kleint 2007-09-05 11:09:30 UTC
Checking in ProjectManager.java;
/cvs/projects/projectapi/src/org/netbeans/api/project/ProjectManager.java,v  <--  ProjectManager.java
new revision: 1.33.2.1; previous revision: 1.33
don
Comment 4 Martin Krauskopf 2007-09-06 08:42:20 UTC
Fresh trunk build from this morning (CET), hours or two old. Reproduced again. Again the similar problem without
exception. This time with read access only. Attaching thread dump. The fix was not sufficient, so reopening this one. I
can file a new one if you want.
Comment 5 Martin Krauskopf 2007-09-06 08:43:05 UTC
Created attachment 48231 [details]
deadlock.txt with read access
Comment 6 Milos Kleint 2007-09-06 13:33:34 UTC
Created attachment 48262 [details]
second patch
Comment 7 Milos Kleint 2007-09-06 13:40:50 UTC
The following scenario was not covered by previous fix:
ProjectA gets created, in createProject() calls findProject() on projectB and then findProject() on itself (projectA).

Now we keep a list of project folder FileObjects that are procesed by current thread. See patch.
Comment 8 Jesse Glick 2007-09-06 16:30:17 UTC
Again may be slightly clearer to @Override initialValue() -> new HashSet<FileObject>().
Comment 9 Petr Nejedly 2007-09-07 08:09:50 UTC
No, please.
You'd trade one/two conditions for a whole class, that's unnecessary waste.
Comment 10 Martin Krauskopf 2007-09-07 08:40:10 UTC
If it is dangerous to fixthis, I would vote for removing previously applied patch from the beta1 branch. The only
steps/trigger which reproduced/caused this so far was usage of VisibilityQuery in the Rails project. The VisibilityQuery
is not and will not be used in the beta1 branch. For now we have used workaround in Rails project. So maybe this could
be waived.
Comment 11 Milos Kleint 2007-09-07 09:05:37 UTC
Checking in ProjectManager.java;
/cvs/projects/projectapi/src/org/netbeans/api/project/ProjectManager.java,v  <--  ProjectManager.java
new revision: 1.33.2.2; previous revision: 1.33.2.1
done


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