[antlr-interest] error reporting problem in C runtime

Jim Idle jimi at temporal-wave.com
Tue Jul 13 08:26:19 PDT 2010


I'll take a look. It is possible that something like that might have been overlooked as I am trying to reuse the memory and not keep freeing and mallocing exceptions.

Jim 

> -----Original Message-----
> From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
> bounces at antlr.org] On Behalf Of Davis, Alan
> Sent: Tuesday, July 13, 2010 6:51 AM
> To: antlr-interest at antlr.org
> Subject: [antlr-interest] error reporting problem in C runtime
> 
> I'm having a problem with error handling in the C target. In a file
> with multiple recognition failures on different lines, the second error
> is being reported with the same line number and proximity token as the
> first.
> 
> I think I have tracked down the problem but it seems incomprehensible
> that such a blatant problem would still be extant, so I'm wondering if
> I'm overlooking something.
> 
> The first recognition error causes an exception object to be created
> and recorded in recognizer->state->exception. However I cannot find
> anywhere where exceptions are freed. That is, after the first
> exception, recognizer->state->exception is never NULL; it continues to
> point to the first exception indefinitely.
> 
> The second error is a token mismatch, which results in a call to
> recoverFromMismatchedToken(), which does:
> 
>  // Create an exception if we need one
>  if (recognizer->state->exception == NULL)
>     antlr3RecognitionExceptionNew(recognizer);
> 
> The predicate fails because the first exception is still there... so
> the constructor is not called... so the fields pinpointing the error
> are not set... so the second error is reported with the same source
> filename and line number as the first.
> 
> I was able to fix this by overriding reportError(), adding code to call
> freeEx() and set recognizer->state->error to NULL. But it seems like
> this would be part of the standard library implementation -- or at
> least there would be something to take care of this.
> 
> My apologies if this a known issue -- I searched the various
> FAQs/Wikis/groups as best as I could.
> 
> Regards,
> Alan Davis
> Texas Instruments
> 
> 
> 
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-
> email-address





More information about the antlr-interest mailing list