Bug 414003 - Re-producable Deadlock in case of "missing" Action in grammar
Summary: Re-producable Deadlock in case of "missing" Action in grammar
Status: NEW
Alias: None
Product: TMF
Classification: Modeling
Component: Xtext (show other bugs)
Version: 2.4.2   Edit
Hardware: PC Windows 8
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-30 09:24 EDT by Robert Walter CLA
Modified: 2013-08-14 04:32 EDT (History)
3 users (show)

See Also:


Attachments
grammar, test file, and stack dump (3.97 KB, application/zip)
2013-07-30 09:24 EDT, Robert Walter CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Walter CLA 2013-07-30 09:24:20 EDT
Created attachment 233937 [details]
grammar, test file, and stack dump

I boiled down my grammar to the possible minimum to illustrate what I believe is a re-producable deadlock. Here's the grammar you can use in a default Xtext project (also attached). Note that I tried this with the latest release (2.4.2) as well as the bleeding edge version of Xtext (2.4.3.v201307291041):

#############################################################
grammar org.xtext.example.mydsl.MyDsl with org.eclipse.xtext.common.Terminals

generate myDsl "http://www.xtext.org/example/mydsl/MyDsl"

Script:
	charactersDefinition=CharactersDefinition?
	scenes+=Scene*;

CharactersDefinition:
	'characters' ':' characters+=CharacterDefinition (',' characters+=CharacterDefinition)*;

CharacterDefinition:
	name=ID;

Scene:
	'scene' description=STRING
	dialog=Dialog
	'end' 'scene';

Dialog://{Dialog} 
	defaults=Defaults
	hubs+=Hub*;

Defaults: {Defaults}
	dialogLines+=DialogLine*;

Hub:
	'hub' name=StringID
		choiceDialogs+=ChoiceDialog*
	'end';

StringID:
	STRING;

ChoiceDialog:
	modifiers=Modifiers 'choice' name=StringID? 
		dialogLines+=DialogLine*
	'end';

Modifiers:{Modifiers}
	single?='single'?  random?='random'?
;

DialogLine:
	character=[CharacterDefinition] ':' lines=STRING;
#############################################################

The grammar shows no warnings.
Write a program using this language, which looks like this:

#############################################################
characters: Foo, Bar

scene "Test"
 
	hub "Foo"
		choice "Foo"
	   		Foo: "foooo"
	  	end 
	  	
	  	// here you need to proceed to reproduce the deadlock...
	end

end scene
#############################################################
Save the above state once and then, manually(!), type the following at the marked position: 

	choice "" 

and, when the cursor is just inside the quotation marks, invoke the content assist feature (CTRL+SPACE).

This should lead to a re-producable deadlock. I attached the corresponding stack dump. The deadlock seems to appear when the main thread tries to acquire a read lock.


I found two possible changes I can do to my grammar so that the deadlock does not appear.

1. Add the {Dialog} Action to the dialog rule (maybe the Xtext grammar should display another warning here that the action is missing since the "Defaults" rule might be empty?)

2. Change the "Modifiers" rule to an unordered group, which, however, led to other problems I cannot recall right now:

Modifiers://{Modifiers}
	single?='single'? & random?='random'?
;
Comment 1 Holger Schill CLA 2013-08-13 09:33:45 EDT
Could break that down to this grammar:

grammar org.xtext.example.mydsl.MyDsl with org.eclipse.xtext.common.Terminals

generate myDsl "http://www.xtext.org/example/mydsl/MyDsl"


Root:
	'root' name=STRING
		child+=Child*
	'end';

Child: 
	element=Element 'child' name=STRING
	'end';

Element:{Element}
	name="FOO"?
;


The problem seems to be the rule Child and it's first assignment in combination with the identical keyword "end" from rule Root and Child.

Given this instance nothing wents wrong:

root "root" 
	child end
end

when you have this instance:

root "root" 
	child // Edit here!
end

And you try to edit at the described location the deadlock in the parser appears.

If you change the keyword "end" at the end of rule root to "endroot" it works.
If the Rule Element has a non optional assignment it works.
If you remove the assignment element in rule Child it works.
Comment 2 Holger Schill CLA 2013-08-13 10:37:59 EDT
Seema like line line 163 in org.xtext.example.mydsl.parser.antlr.internal.InternalMyDslParser loops to death because the loops keeps going even if LA1_0 is EOF. Removing this "LA1_0==EOF||" seems to solve the problem.

do while(true)
...
if ( (LA1_0==EOF||(LA1_0>=13 && LA1_0<=14)) ) {
                    alt1=1;
}

Hopefully this helps to find the real issue.
Comment 3 Sebastian Zarnekow CLA 2013-08-14 04:32:06 EDT
I doubt that this is something that we can fix in the 2.4.3 timeframe.
Comment 4 Sebastian Zarnekow CLA 2013-08-14 04:32:44 EDT
You should try to avoid production rules that do not consume any input, e.g.

ParserRule: {ParserRule} 'optional'?;