Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 198488 - deadlock with OrganizeImports plugin
deadlock with OrganizeImports plugin
Status: RESOLVED FIXED
Product: java
Classification: Unclassified
Component: Editor
7.1
PC Windows XP
: P1 (vote)
: 7.2
Assigned To: Jan Becicka
issues@java
http://kenai.com/jira/browse/ORGANIZE...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-10 17:52 UTC by err
Modified: 2011-06-06 14:01 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
two threads look like they are deadlocked (10.92 KB, text/plain)
2011-05-10 17:52 UTC, err
Details

Note You need to log in before you can comment on or make changes to this bug.
Description err 2011-05-10 17:52:38 UTC
Created attachment 108215 [details]
two threads look like they are deadlocked

I downloaded this "featured plugin" at the plugin portal, and decided to make a jVi colon command to invoke it. While running a copy of the IDE under the debugger I have seen this deadlock a few times.

Looks like the plugin is invoking JavaSource.runModificationTask and from what I could see in the javadoc there's no mention of the document lock. I've cc'd the listed owner of the plugin.

I don't know how to get a complete thread dump in the debugger, but I copied and attached the thread stacks that seem to be involved.
Comment 1 Tomas Zezula 2011-05-10 18:06:09 UTC
The problem is in the:

sun.misc.Unsafe.park(Unsafe.java)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:842)
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1178)
java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:201)
java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:191)
org.netbeans.modules.parsing.api.ParserManager.parse(ParserManager.java:106)
org.netbeans.api.java.source.JavaSource.runUserActionTaskImpl(JavaSource.java:432)
org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.java:403)
org.netbeans.api.java.source.JavaSource.runModificationTask(JavaSource.java:678)
com.kenai.organizeimports.core.GroupImport.resortGroups(GroupImport.java:125)
com.kenai.organizeimports.core.GroupImport.access$300(GroupImport.java:37)
com.kenai.organizeimports.core.GroupImport$1.run(GroupImport.java:106)
org.netbeans.editor.GuardedDocument.runAtomicAsUser(GuardedDocument.java:344)
com.kenai.organizeimports.core.GroupImport.invoke(GroupImport.java:100)

The ParserManager.parse is called under document wl, this is forbidden.
The correct lock ordering is paring lock followed by document lock.
The issue should be reported to com.kenai.organizeimports.core.GroupImport.
Comment 2 Tomas Zezula 2011-05-10 18:15:14 UTC
I've created a new issue for organizeimports: http://kenai.com/jira/browse/ORGANIZEIMPORTS-1
Comment 3 Tomas Zezula 2011-05-10 18:19:05 UTC
We should probably return back the check of wrong lock ordering and throw an IllegalStateException.
Unfortunately it's not very nice code it has to use reflection to find it out.
Also paprsing.api javadoc should be improved, I will do it.
Comment 4 err 2011-05-10 18:31:28 UTC
I didn't write the plugin, but I'm curious. It uses
    JavaSource.runModificationTask
but I don't see the plugin task being called. So I guess it hasn't gotten there yet?

I guess I'm saying the discussion about locking in JavaSource javadoc should mention the issue. IIUC, the plugin should not call JavaSource from runAtomicAsUser. It should instead do its "atomic" stuff in the runModificationTask.
Comment 5 err 2011-05-10 19:02:07 UTC
> should probably return back the check of wrong
> lock ordering and throw an IllegalStateException.
> it has to use reflection to find it out.

Couldn't AbstractDocument.getCurrentWriter() be used?
Comment 6 Tomas Zezula 2011-05-12 14:03:36 UTC
The problem is that the JavaSource.runModificationTask is called from GuardedDocument.runAtomicAsUser. Only the ModificationResult.commit should be called from from GuardedDocument.runAtomicAsUser (if needed). The ModificationResult.commit does automatically NbDocument.runAtomic.
Comment 7 Jan Becicka 2011-06-06 13:49:18 UTC
Organize imports moved to "organize_imports" branch. This bug is now valid.
Comment 8 Jan Becicka 2011-06-06 14:01:19 UTC
Changeset: http://hg.netbeans.org/jet-main/rev/e868a88f6091
Author:    Jan Becicka <jbecicka@netbeans.org>
Date:      2011-06-06 15:59
Message:   
Issue #198488 - deadlock with OrganizeImports plugin


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