[antlr-interest] gUnit freezing when choking on invalid input

[Thomas Vial]

Hi,

I have tested your fix and it works perfectly.

Many thanks again!! All the more useful as I'm not ready to go with ANTLR
3.1b yet.

Thomas



On Sat, Jun 28, 2008 at 8:06 PM, Leon Su <leonsu at mac.com> wrote:

>
> On Jun 28, 2008, at 7:40 AM, Thomas Vial wrote:
>
> Wow that was quick :-)
> I'll give it a try and post the results here. Thanks a lot for your
> reactivity!
>
> What I love with gUnit is the clean syntax: input --> expected result,
> especially with ASTs. It's just what unit testing is for: testing code of
> course AND documenting it with examples.
>
>
> Cool. I'm planning to work on the next version of gUnit and will make it
> more robust and usable :)
>
> Thomas
>
> PS : hope you don't mind my replying to the mailing list, so that everybody
> can try too
>
>
> Sure. It's good to share your thought or questions on the mail list. That
> also helps me debug and improve gUnit
>
> Leon
>
>
> On Sat, Jun 28, 2008 at 5:17 AM, Leon Su <leonsu at mac.com> wrote:
>
>> Hi, I've  updated the gunit-1.0.1.jar on the wiki download page.
>> Please let me know if there's any other issue.
>> Thanks.
>>
>> Leon
>>
>> On Jun 27, 2008, at 2:55 AM, Thomas Vial wrote:
>>
>>  Hi all,
>>>
>>>
>>> I am experiencing an annoying issue with gUnit freezing when parsing
>>> of test input fails. Here is my test case, with ANTLR v3.0 and gUnit
>>> 1.0.1.
>>>
>>> ----------[Expr.g]----------------------
>>> grammar Expr;
>>>
>>> options {
>>>        output=AST;
>>> }
>>>
>>> tokens {
>>>        PROG;
>>> }
>>>
>>> @header {
>>> package com.expr;
>>> }
>>>
>>> @lexer::header {
>>> package com.expr;
>>> }
>>>
>>> program:
>>>        (expr ';')*                                                     ->
>>> ^(PROG expr*)
>>> ;
>>>
>>> // The following rules are deliberately incorrect
>>> // Should be expr1 ('+' expr1)* and expr2 ('*' expr2)*
>>> // for a real expression parser :-)
>>> expr:
>>>        expr1 '+' expr1                                         -> ^('+'
>>> expr1 expr1)
>>> ;
>>>
>>> expr1:
>>>        expr2 '*' expr2                                         -> ^('*'
>>> expr2 expr2)
>>> ;
>>>
>>> expr2:
>>>        INTEGER                                                         ->
>>> INTEGER
>>> |       '(' expr ')'                                            -> expr
>>> ;
>>>
>>>
>>> INTEGER:
>>>        ('0'..'9')+
>>> ;
>>> -------------------------------------------
>>>
>>>
>>> ----------[Expr.testsuite]-----------
>>> gunit Expr;
>>>
>>> @header {
>>> package com.expr;
>>> }
>>>
>>> expr:
>>>        "1+2"                           -> (+ 1 2)
>>> -------------------------------------------
>>>
>>>
>>> With this input, gUnit freezes indefinitely. When feeding the parser
>>> directly, I get "line 0:-1 mismatched input '<EOF>' expecting '*'",
>>> which is correct wrt the badly written grammar (see comments above
>>> rules expr and expr1). However gUnit does not see the error and gets
>>> stuck. I have noticed, by looking at the JUnit code that gUnit
>>> generates with the -o option (the JUnit version of the test freezes,
>>> too), that it internally uses threads to pass input to the parser and
>>> retrieve its output. The issue might have something to do some thread
>>> starving on a reader.
>>>
>>> This is annoying when run from the command line: the whole test suite
>>> freezes, so you have to execute the parser against every test by hand
>>> to track the actual error. This also makes gUnit unusable in
>>> continuous integration scenarii.
>>>
>>> Another oddity is that gUnit behaves as expected, i.e. reporting the
>>> error, when the AST construction is done inline:
>>> -------------------------------------------
>>> expr:
>>>        expr1 '+'^ expr1
>>> ;
>>>
>>> expr1:
>>>        expr2 '*'^ expr2
>>> ;
>>> -------------------------------------------
>>>
>>> Shouldn't both construction methods be equivalent?
>>>
>>>
>>>
>>>
>>> Any insights on these issues?
>>>
>>> Thanks!
>>>
>>> Thomas
>>>
>>
>>
>
>
> --
> ..........................................................
> Thomas VIAL
> OCTO Technology
> ..........................................................
> 50, Avenue des Champs-Elysées
> 75008 Paris
> Tél : (33) 1 58 56 10 00
> Fax : (33) 1 58 56 10 01
> GSM : (33) 6 28 50 07 64
> Web : http://www.octo.com/
> ..........................................................
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20080630/1d3017d9/attachment.html