This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
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.
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.
I've created a new issue for organizeimports: http://kenai.com/jira/browse/ORGANIZEIMPORTS-1
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.
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.
> 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?
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.
Organize imports moved to "organize_imports" branch. This bug is now valid.
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