[antlr-interest] C++ Crash in consumeUntil()

Ric Klaren ric.klaren at gmail.com
Wed Jan 25 04:41:28 PST 2006


On 1/25/06, Andrew Bell <andrew.bell.ia at gmail.com> wrote:
> I am throwing a SemanticException in a parser action.  It gets caught
> by the default handler which catches the exception as a
> RecognitionException.  The exception handler calls reportError() and
> then dies when it calls recover().  Here's the stack trace:
>
> #0  0x0000000000523cdd in antlr::TokenBuffer::LA ()
> #1  0x000000000043d343 in antlr::Parser::consumeUntil ()
> #2  0x00000000004bd227 in StageParser::stagename ()
> #3  0x00000000004bd975 in StageParser::stage ()
> #4  0x00000000004bdc3c in StageParser::lang ()
>
> Since I didn't build with debug, I don't get all of the inlined code
> in the trace.
>
> Anyway, the problem seems to be that recover(), calls consume()
> without regard to whether there is anything to consume.  This
> condition would be caught by the assert clause in
> CircularQueue::removeItems() in debug mode, but the assert is a NOOP
> if not build with debug.  I think that part of this problem is that
> there is an assumption that if an exception is thrown in an action, no
> match has been made.  This is not the case in my circumstance.

Could you cut this down to an small example+input that demonstrates it
and send it to me so I can look at stuff offline (currently without
internet which is quite a bother..)

> Anyway, this seems to be a bug/hard to recognize issue in the C++
> runtime.  Does anyone have any ideas on how to best deal with this?

You could try removing the assert and make removeItems just plain
return in those cases. The triggering of the assert sometimes points
at a problem in the grammar mostly related to rules matching nothing.
There are no clear pre/post conditons of many of these methods. As a
result I'm usually not really enthousiastic about changing something
without proper analysis.

Another (maybe better?) option is to override recover to check wether
the consume makes sense.

Throw something different than a semantic exception if that's an
option? And/or adapt the error handler for the case.

> Also, it has been about 7 years since I last used ANTLR and it STILL
> doesn't appear have an option to set filename suffixes on generated
> files for C++ output.  If I add such, would someone be willing to
> accept/integrate?

If it's a clean patch (e.g. implementing a C++ file level option) then
it should not be a problem to include. I prefer unified diffs or send
me the (minimally) changed files (starting from the latest release
preferably)

Cheers,

Ric


More information about the antlr-interest mailing list