Description Kevan Holdaway 2011-01-31 17:00:13 EST

Build Identifier: M20110112-0800

Our product add their own positions to the documents of open editors.  We use the standard eclipse org.eclipse.jface.text.IDocument.addPosition(String, Position) and org.eclipse.jface.text.IDocument.removePosition(String, Position) methods.

SynchronizableDocument fires events inside of the same lock it uses for addPosition/removePosition.  This can cause a deadlock.  Firing events in a lock is poor design as it puts an expectation on clients who handle the code.

Here is a sample stack trace found in a deadlock we experienced:
org/eclipse/jface/text/AbstractDocument.fireRewriteSessionChanged(Bytecode PC:50)
org/eclipse/jface/text/AbstractDocument.stopRewriteSession(Bytecode PC:87)
org/eclipse/core/internal/filebuffers/SynchronizableDocument.stopRewriteSession(Bytecode PC:21)

Note the code for stopRewriteSession:
	public void stopRewriteSession(DocumentRewriteSession session) {
		Object lockObject= getLockObject();
		if (lockObject == null) {
			super.stopRewriteSession(session);
			return;
		}
		synchronized (lockObject) {
			super.stopRewriteSession(session);
		}
	}

It makes the call to super.stopRewriteSession inside of the synchronized block.  This caused our product a deadlock.  

Reproducible: Sometimes