[antlr-interest] Re: failed assertion in CircularQueue.hpp

Ric Klaren ric.klaren at gmail.com
Tue Jul 11 08:25:22 PDT 2006


Hi,

On 7/11/06, Scott Amort <jsamort at gmail.com> wrote:
> Scott Amort wrote:
> > scripts/../lib/cpp/antlr/CircularQueue.hpp:59: void
> > antlr::CircularQueue<T>::removeItems(size_t) [with T =
> > antlr::TokenRefCount<antlr::Token>]: Assertion `nb <= entries()' failed.
>
> Sorry to be a pain, but has anyone encountered this before?  Testing my
> library has ground to a halt until I can figure this one out.

There have been a few reports of people triggering this assert. It's
on my antlr 2.7 todo list. But so far I lacked a concise example that
triggered it. If you can get me a somewhat minimal example that
triggers it. (compiling code + input) Then I can look at it. If I have
to reconstruct the problem myself then it will probably stay shelved
untill my holidays.

> It seems to be related to my throwing a SemanticException from within
> the parser (during some validation).  Here is the actual code that
> triggers it:
>
> if ( node->getFirstChild()->getType() == GTokenTypes::GTaggedRange ) {
>   if ( node->getText() != "requiredrange" ) {
>     throw antlr::SemanticException(
>       "tag: '\\" + node->toString() + "' is missing required tagged range",
>       getFilename(),
>       node->getLine(),
>       node->getColumn());
>   }
> }

It's probably significant to know the grammar construct in which it is
used (and it may also be dependant on the input)

> Nothing out of the ordinary, I don't think, and I use similar code in
> numerous other places in the parser with no ill effect.  The only
> possible difference I can see is that GTaggedRange is a dummy token type
> that I manually created during parsing i.e. with:

I strongly doubt wether it is the imaginary token. I would search
along the lines of newly introduced syntactic/semantic predicates or a
change in the test input.

> The failed assertion only began showing up once I introduced this dummy
> header token, but it could be coincidence (and I have used other dummy
> header tokens without problems in other parts of the parser).
>
> I realize everyone is working hard on the upcoming ANTLR3,

I wish I was working on ANTLR3 ;) (or able to sync up on 2 stuff)

> but if someone could spare a few moments to help me out, I would really
> appreciate it!

My time is pretty limited but I'll try and have a look again. If you
can provide code to reproduce it, then that would speed things up
significantly.

Cheers,

Ric


More information about the antlr-interest mailing list