This applies at least to versions:
- 0.5.3.4 unstable
- org.strategoxt.runtime SVN 21256

The situation occurrs if content completion fails due to a null AST (because the parser failed).

The failure of the content completion will lead to two possible outcomes: the main thread crashes completely (1) or a deadlock occurrs with the main thread trying to acquire the lock from one of the worker threads (2).

The stack trace produced is at http://pastebin.com/NZ41CLtk

The “LOCK REQUESTED BY” and “LOG RELEASED BY” stdout messages were added to see which thread was not releasing.

Steps for reproducing follow:

1. Fresh workspace
2. Create default project using wizard
3. Add completion trigger for letters:
   completion trigger : “[A-Za-z]+”
4. Replace the contents of the example source file (example.YOUREXTENSION) with:
   1 /*

       2 SOMETHING
   
       3 
   
       4 */
   
       5
   

(numbers above indicate line numbers).

The idea with the source is to create a file which produces an empty AST. In this case just LAYOUT.
5. Build
6. Start typing alpha characters on line 3, combine with spaces.
7. If you type fast enough you should reproduce.

Analysis:

The parser fails because it only parses layout and then sees EOF. (A) This produces a null AST which leads to a NPE during completion. (B)

(A): can confirm that the above situation does not occur if the file actually includes at least one production.

I’ve tried protecting from (B) by:

===================================================================
--- ContentProposer.java	(revision 21256)
+++ ContentProposer.java	(working copy)
@@ -122,7 +122,10 @@
 			return createErrorProposal("No proposals available - completion lexical must allow letters and numbers", offset);
 		
 		RootAstNode ast = constructAst(getParser(controller), offset, document);
-		Set<String> sorts = new AstSortInspector(ast).getSortsAtOffset(offset - currentCompletionPrefix.length(), offset);
+		Set<String> sorts = null;
+		if(ast!=null)
+			sorts = new AstSortInspector(ast).getSortsAtOffset(offset - currentCompletionPrefix.length(), offset);
+		
 		if (currentCompletionNode == null)
 			return getParseFailureProposals(controller, document, offset, sorts);

This seems to work around the problem and prevent the crashes. Although rarely, other deadlocks do occurr which i think are caused by other problems.

Submitted by Vlad Vergu on 28 September 2010 at 18:33

Thanks for the detailed bug report and problem analysis. Revision 21258 should address the null-pointer exception (to be released after 0.5.3.5).

The content completion deadlock is also documented in Spoofax/252. I’ll add a link to your description as it seems like this is one way that makes it relatively easy to reproduce, as the analysis thread marking errors and content completion are likely to run at the same time in this scenario. The root of the problem there is that Eclipse starts the content completion handler in the GUI thread.