bug#41824: Dejagnu's unknown proc aborts testsuite run when triggered in test-case

Jacob Bachmeyer <[email protected]> Thu, 25 Jun 2020 20:53:46 -0500
Newsgroups gmane.comp.sysutils.dejagnu.bugs
Message-ID <[email protected]>
Rob Savoye wrote:
> On 6/25/20 10:01 AM, Pedro Alves wrote:
>   
>   Adding an additional call makes it harder to diff the .sum files. Not
> a huge big deal, but still... UNRESOLVED says a human has to look at
> this test case output and decide, the actual error should be in the .log
> file. UNTESTED means something went wrong with the test, and the test is
> invalid, which is probably what you'd want as the test state for a Tcl
> error.
>   

The original rationale for using UNRESOLVED here was that DejaGnu 
converts a test result to UNRESOLVED if too many errors or warnings were 
produced.  The DejaGnu manual indicates (section "A POSIX Compliant Test 
Framework") that UNRESOLVED is correct for a test where execution was 
interrupted or was set up incorrectly.  UNTESTED is specifically listed 
as a placeholder for an as-yet-unwritten testcase.  A "typical" GDB 
testsuite run has almost a hundred UNTESTED results but (without this 
patch) zero UNRESOLVED results.

To me, this seems that UNRESOLVED is correct here, or that the manual 
has an error.

>> Currently with DejaGnu only the case of calling an unknown function stops
>> the test run AFAIK.  Any other tcl error like calling a proc with the wrong
>> number of arguments, or treating a non-array variable as an array, etc. is
>> caught by the catch in the runtest proc in runtest.exp, and the testrun
>> continues.  That to me clearly indicates that the original intention was
>> to catch errors and continue.
>>     
>
>   The original intent was to catch some errors, nd ignore others. :-)
> Catch is used for errors that can be ignored or worked around. Unknown
> was basically to catch programming errors, since as noted, there are
> many paths though the code as you change options or environments. They'd
> get lost in the output unless it aborted.
>   

So continuing with the next test script could be reasonable if the error 
(or at least an indication that the error occurred) is "replayed" at the 
end of the test run?

>> It is just that the "unknown" case wasn't thought of.  So I argue that not
>> making unknown proc calls abort the run is a bug fix, and making DejaGnu
>> abort the run for other errors by default is a behavior change that no real
>> testsuite built around DejaGnu is asking for.
>>     
>
>   I think the default should be to abort on a unknown Tcl error, and
> have an option to ignore them and continue. As a person that has run
> many long test runs, I agree I don't want some errors to abort the test
> run. But to be honest, a dependable test run should mean no bugs in the
> test framework. A buggy test framework means you can trust the test results.
>
>   Aborting was for use during debugging of test framework code itself,
> so supposedly you should should never have an Tcl error during a test
> run. There are times when even during debugging you'd want it to
> continue, and then collect all the bugs later to fix in batch mode.
>   

This succinctly states the original motivation for having the 
--keep-going option, but having "make check" always pass --keep-going 
defeats the purpose.


-- Jacob



_______________________________________________
Bug-dejagnu mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-dejagnu