Bug 57710 - Hang/deadlock on opening project
Hang/deadlock on opening project
Status: RESOLVED FIXED
Product: projects
Classification: Unclassified
Component: Generic Infrastructure
4.x
All All
: P1 (vote)
: 4.x
Assigned To: Petr Hrebejk
issues@projects
: THREAD
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-10 18:04 UTC by _ tboudreau
Modified: 2005-04-13 16:59 UTC (History)
0 users

See Also:
Issue Type: DEFECT
:


Attachments
stack trace (19.97 KB, text/plain)
2005-04-10 18:04 UTC, _ tboudreau
Details
Proposed fix (3.58 KB, patch)
2005-04-12 13:26 UTC, Petr Hrebejk
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description _ tboudreau 2005-04-10 18:04:21 UTC
I restarted with contrib/editorhints set as a CVS dir and open as a project, and then tried to open contrib/
editorhints/java.  The event thread becomes permanently blocked.  See attached stack trace.
Comment 1 _ tboudreau 2005-04-10 18:04:53 UTC
Created attachment 21522 [details]
stack trace
Comment 2 Martin Entlicher 2005-04-11 10:54:11 UTC
This appears after the fix of issue #57352. Since it was merged into 4.1 branch,
the deadlock can occur in 4.1 as well.

Evaluating whether there is some other solution then rollback the fix of issue
#57352. It's a mess.
Comment 3 _ tboudreau 2005-04-11 12:40:35 UTC
100% reproducible on my mac.

From the stack trace, looks as if you could invokeLater
org.netbeans.modules.vcscore.actions.GeneralCommandAction.enable(GeneralCommandAction.java:139) 
and it would probably get  it out of the way of other locks.
Comment 4 Martin Entlicher 2005-04-11 12:59:28 UTC
IMHO it's not a fault of VCS.
In AWT thread projects are calling foreign code under a lock, which seems to
cause the deadlock.
Moving to projects.
Comment 5 Martin Entlicher 2005-04-11 13:02:50 UTC
Tim, I see. There are more points which could resolve the deadlock (do not
synchronize instace creation in FolderInstance and do not fire change events
from lookup when someone is doing a query). But the deadlock can occur in other
ways if only some branches are eliminated. The real cause is IMHO calling an
unknown code under the lock.
Comment 6 Jesse Glick 2005-04-11 17:49:35 UTC
OpenProjectList should not use special synchronization, it should be using
ProjectManager.mutex. CloseProject.refresh should be rescheduled to EQ, I guess.
OpenProjectList should use extreme caution when calling foreign code (CES.open)
while holding a lock.
Comment 7 Petr Hrebejk 2005-04-12 13:26:05 UTC
Created attachment 21569 [details]
Proposed fix
Comment 8 Petr Hrebejk 2005-04-12 13:32:50 UTC
OK. Fixed in 4.2. Tim please verify 

> OpenProjectList should not use special synchronization, it should be using
> ProjectManager.mutex. 

There is no reason for that. OPL only needs to keep it's internal data. Why to
lock on some global mutex. 

> CloseProject.refresh should be rescheduled to EQ, I guess.

Should not be necessary now.

> OpenProjectList should use extreme caution when calling foreign code 
> (CES.open) while holding a lock.

It does. Better said it did before someone else added the calls to external code
into synchroinized block. Btw. you should check where you are adding
notifyOpened() calls as well. I fixed those in OPL.open(). But the one in the
OPL constructor still causes that some people get NULL from
OpenProjects.getDefault()

Checking in src/org/netbeans/modules/project/ui/OpenProjectList.java;
/cvs/projects/projectui/src/org/netbeans/modules/project/ui/OpenProjectList.java,v
 <--  OpenProjectList.java
new revision: 1.31; previous revision: 1.30
done
Comment 9 Petr Hrebejk 2005-04-13 16:59:50 UTC
Fixed in 4.1

Checking in src/org/netbeans/modules/project/ui/OpenProjectList.java;
/cvs/projects/projectui/src/org/netbeans/modules/project/ui/OpenProjectList.java,v
 <--  OpenProjectList.java
new revision: 1.30.4.1; previous revision: 1.30
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