Bug 143201 - Deadlock in AntBuildExtender
Deadlock in AntBuildExtender
Status: RESOLVED FIXED
Product: projects
Classification: Unclassified
Component: Ant Project
6.x
All All
: P2 (vote)
: 6.x
Assigned To: Milos Kleint
issues@projects
: THREAD
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-07 16:49 UTC by Milan Kuchtiak
Modified: 2008-08-14 15:52 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


Attachments
Thread dump (9.02 KB, text/plain)
2008-08-07 16:50 UTC, Milan Kuchtiak
Details
New deadlock (25.83 KB, text/plain)
2008-08-12 12:52 UTC, Milan Kuchtiak
Details
Correct dump stack (8.89 KB, text/plain)
2008-08-12 12:55 UTC, Milan Kuchtiak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Milan Kuchtiak 2008-08-07 16:49:19 UTC
Is that correct there are code parts in AntBuildExtender which are synchronized on Class object :

Sample 1 :
         public void addDependency(String mainBuildTarget, String extensionTarget) {
            ...
            synchronized (AntBuildExtender.class) {
                ...
            }
        }

Sample 2 :

        Map<String, Collection<String>> getDependencies() {
            ...
            synchronized (AntBuildExtender.class) {
                ...
            }
            ...
        }
Comment 1 Milan Kuchtiak 2008-08-07 16:50:16 UTC
Created attachment 66834 [details]
Thread dump
Comment 2 Jesse Glick 2008-08-07 21:19:31 UTC
Should probably be using ProjectManager.mutex.
Comment 3 Milan Kubec 2008-08-07 22:33:33 UTC
Reassigning to Milos.
Comment 4 Milos Kleint 2008-08-08 11:01:08 UTC
I've made the synchronization based on AntBuildExtender instance, not class. Assuming the 2 threads each worked on top
of different projects, the change should fix it.
http://hg.netbeans.org/main/rev/8a553f8b7fed

if you can still reproduce with this patch in, please add steps to reproduce and reopen.

jglick: not sure how project mutex shall help. Both threads were already using project write mutex down the stack traces..
Comment 5 Jesse Glick 2008-08-08 14:57:54 UTC
"Both threads were already using project write mutex" - no. The first thread was using PM.mutex write, and waiting for
ABE. The second thread held ABE and was _trying_ to use PM.mutex write - hence the deadlock: a lock ordering conflict.
Changing synchronization to an instance of ABE is unlikely to make any difference (assuming both threads were dealing
with the same project). You need to remove use of any other monitor and use only PM.mutex.

The thread dump is confusing because it looks like the top of the second thread is inside PM.mutex write access. In fact
if you look at JavaEEWSSupportLookupProvider.java you'll see that the body of the mutex access is calling
jaxWsModel.write(). The second thread is not in this Runnable any more; it is exiting the FS.AtomicAction, which is then
notifying FS listeners (I hope without holding PM.mutex any longer). That is to say, the top of the second thread could
as well have been something like

...
EjbJaxWsLookupProvider$1$2.fileChanged
...
FCLSupport.dispatchEvent
...
<some unrelated FS call>
...
RequestProcessor$Processor.run
Comment 6 Quality Engineering 2008-08-08 15:48:00 UTC
Integrated into 'main-golden', available in build *200808081401* on http://bits.netbeans.org/dev/nightly/
Changeset: http://hg.netbeans.org/main/rev/8a553f8b7fed
User: Milos Kleint <mkleint@netbeans.org>
Log: #143201 synchronize on instance, not class
Comment 7 Milan Kuchtiak 2008-08-12 12:52:44 UTC
Created attachment 67138 [details]
New deadlock
Comment 8 Milan Kuchtiak 2008-08-12 12:55:13 UTC
Created attachment 67139 [details]
Correct dump stack
Comment 9 Milan Kuchtiak 2008-08-12 12:58:05 UTC
Please ignore the 67138 attachment, 67139 is the right one. 
Comment 10 Milan Kuchtiak 2008-08-12 14:33:50 UTC
Please, don't add dependencies if they are already there.
There is no way in Ant Extender API to check if dependencies are already set or not.
Comment 11 Milos Kleint 2008-08-13 09:05:23 UTC
http://hg.netbeans.org/main/rev/bf43dde96edf
adding checks to AntBuildExtender to persist data only in case something actually changes.
Comment 12 Quality Engineering 2008-08-14 15:52:35 UTC
Integrated into 'main-golden', available in build *200808141419* on http://bits.netbeans.org/dev/nightly/
Changeset: http://hg.netbeans.org/main/rev/bf43dde96edf
User: Milos Kleint <mkleint@netbeans.org>
Log: #143201 only persist data when something actually changes


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