Unfortunately, this fix does not work completely. The bug appears to actually be inside lemon.c, not lempar.c. When trying to shift an error, you can have three cases: ``` (1) it is legal to shift an error (2) it is legal to shift-reduce an error (3) it is legal to reduce ``` In my grammar, (3) only ever appears as the default action for a state. I don't know if that's true in general. The root of the problem IMO is that lemon.c writes yy_action entries for (2) as though they were (3). lemon.c writes error shift actions (1) correctly. The previously applied fix just detects a reduction (3) in the table and replaces it with a shift-reduction (2). Unfortunately, if you actually have case (3), you now incorrectly shift an error and then reduce. This can lead to a mismatch between the current state and the stack, which in the case of my default reduction actions, leads to an infinite loop. So, the correct fix is probably to revert this last fix and find where lemon.c writes the erroneous entry. Also, there's this interesting comment in the code: ``` /* There are no SHIFTREDUCE actions on nonterminals because the table ** generator has simplified them to pure REDUCE actions. */ assert( !(yyact>YY_MAX_SHIFT && yyact<=YY_MAX_SHIFTREDUCE) ); ``` ... but it is exactly this claim which is false for the case of the 'error' non-terminal.