dejagnu
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to abort a test?


From: Simon Marchi
Subject: Re: How to abort a test?
Date: Mon, 18 Jan 2016 11:43:41 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

On 16-01-17 03:27 AM, Joel Brobecker wrote:
> I admit that some of it flying a little over my head... Does it
> mean that we will be able to abort a test if we detect a timeout?
> This is one of the things I wanted to do, but didn't have a solution
> for, so it'd be fantastic if it helped with that!

--status does no really impact how a timeout is handled.  What happens
when a timeout occurs in gdb_test is defined by us.  Right now, it
produces a test "fail":

testsuite/lib/gdb.exp:
  937         timeout {
  938             if ![string match "" $message] then {
  939                 fail "$message (timeout)"
  940             }
  941             set result 1
  942         }

So you see, for example:

  FAIL: gdb.base/break.exp: some test (timeout)

and the test case carries on.  A gdb_test timeout is no different than
a regular fail.  If you replace the "fail" at line 939 with "error",
which throws a TCL exception, then the current test case will abort,
although in this quite ugly way:

  Running /home/emaisin/src/binutils-gdb/gdb/testsuite/gdb.base/break.exp ...
  ERROR OCCURED: some test (timeout)
      while executing
  "error "$message (timeout)""
      invoked from within
  "if ![string match "" $message] then {
                error "$message (timeout)"
            }"
      invoked from within
  "expect {
  -i exp8 -timeout 1
        -re ".*A problem internal to GDB has been detected" {
            fail "$message (GDB internal error)"
            gdb_internal_error_..."
      ("uplevel" body line 1)
      invoked from within
  "uplevel $body" NONE insert breakpoint (timeout)WARNING: remote_expect 
statement without a default case?!

The current test case is stopped and the next .exp is ran.  However,
if you don't use --status on the runtest command line, the uncaught
exception will not be considered as an error.  So if you use
"make check" in a script, you won't notice the failure.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]