avoid java.lang.StackOverflowError

[WolfgangFahl]

see http://stackoverflow.com/questions/31193527/stackoverflowerror-in-antlr4

The LexerATNSimulator should IMHO give up after a certain number of recursions before the StackOverflowError happens and spit out some information what is going on to help debug the grammer that causes the problem.

java.lang.StackOverflowError
    at org.antlr.v4.runtime.atn.LexerATNSimulator.getEpsilonTarget(LexerATNSimulator.java:499)
    at org.antlr.v4.runtime.atn.LexerATNSimulator.closure(LexerATNSimulator.java:480)
    at org.antlr.v4.runtime.atn.LexerATNSimulator.closure(LexerATNSimulator.java:482)
    at org.antlr.v4.runtime.atn.LexerATNSimulator.closure(LexerATNSimulator.java:482)
...

[parrt]

@WolfgangFahl Did you get an error from antlr during code generation? It's an optional token or something.

[parrt]

@WolfgangFahl If this is an issue of actual stack size because of parsing, you can increase the stack size remarkably big in Java ;) Did you see an error message when you generated code? Can I close this?

[Ma124]

@parrt I have the same problem. I increased the stack size but it didn't work.

[WolfgangFahl]

Increasing the stacksize obviously won't help. No please don't close this. It would be helpful to get an avoidance/debug help implemented.

[parrt]

it's an infinite loop issue when someone puts a lexer rule that can match the empty string I believe. detecting infinite loops in that case might be undecidable. (halting problem)

[KvanTTT]

Seems like it's related to #2860

Also, I don't think it's about a halting problem rather a bug in runtime. Because there is stack overflow even for such a simple sample (for input 'x'):

TOKEN1: '\'' FRAGMENT1 '\'';
fragment FRAGMENT1: ('x'|)+;

But everything works fine if an empty alternative is replaced with optional:

TOKEN2: '\'' FRAGMENT2 '\'';
fragment FRAGMENT2: 'x'*;

[WolfgangFahl]

This is definitely not a halting problem since the stack is a limited resource and it should be avoided to overrun the limit. The limit is known and therefore simple counting can decide when the limit is reached (or almost reached).

[KvanTTT]

It seems like I've fixed this case. Lexer should throw EPSILON_CLOSURE on such rules as well as parser does it. For instance, here is another fix for parser: #1477

[KvanTTT]

@parrt it should be closed as well :)

[WolfgangFahl]

@parrt @KvanTTT thanks