Re: [PATCH 1/2] gdb/testsuite: make gdb_test_multiple return immediately if send_gdb fails

[Tom de Vries <tdevries@suse.de>]

On 11/22/22 16:55, Simon Marchi via Gdb-patches wrote:
> From: Simon Marchi <simon.marchi@polymtl.ca>
> 
> In the failure seen by Philippe here:
> 
>    https://inbox.sourceware.org/gdb-patches/20221120173024.3647464-1-philippe.waroquiers@skynet.be/
> 
> ... the testsuite only outputs PASSes, and an ERROR, resulting from an
> uncaught exception.  This is a bit sneaky, because ERRORs are not
> reported in the test summary.  In certain circumstances, it can be easy
> to miss.
> 
> Normally, gdb_test_multiple outputs an UNRESOLVED when GDB crashes.  But > this is only if it manages to send the command, and it's that command
> that crashes GDB.  Here, the ERROR is due to the fact that GDB had
> already crashed by the time we entered gdb_test_multiple and tried to
> send a command.  GDB was crashed by the previous "file" command, sent by
> gdb_unload.  Because gdb_unload uses bare expect, it didn't record a
> test failure when crashing GDB (this will be addressed separately).
> 
> In this patch, I propose to make gdb_test_multiple call unresolved
> directly and return -1 send_gdb fails.  This way, if GDB is already
> crashed by the time we enter gdb_test_multiple, it will leave a trace in
> the test results in the form of an UNRESOLVED.  It will also spare us of

spare us of the -> spare us the ?

> the not-so-useful-in-my-opinion TCL backtrace.
> 

Agreed.

> Before, it looks like:
> 
>      ERROR: Couldn't send python print(objfile.filename) to GDB.
>      ERROR: : spawn id exp9 not open
>          while executing
>      "expect {
>      -i exp9 -timeout 10
>              -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 : spawn id exp9 not open
> 
> And after:
> 
>      Couldn't send python print(objfile.filename) to GDB.
>      UNRESOLVED: gdb.python/py-objfile.exp: objfile.filename after objfile is unloaded
> 

LGTM, thanks for doing this.

Thanks,
- Tom

> Change-Id: I72af8dc0d687826fc3f76911c27a9e5f91b677ba
> ---
>   gdb/testsuite/lib/gdb.exp | 8 ++++++--
>   1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> index 7d05fbe557bb..fcd54c88f251 100644
> --- a/gdb/testsuite/lib/gdb.exp
> +++ b/gdb/testsuite/lib/gdb.exp
> @@ -1161,7 +1161,9 @@ proc gdb_test_multiple { command message args } {
>   	    if { $foo < [expr $len - 1] } {
>   		set str [string range "$string" 0 $foo]
>   		if { [send_gdb "$str"] != "" } {
> -		    perror "Couldn't send $command to GDB."
> +		    verbose -log "Couldn't send $command to GDB."
> +		    unresolved $message
> +		    return -1
>   		}
>   		# since we're checking if each line of the multi-line
>   		# command are 'accepted' by GDB here,
> @@ -1180,7 +1182,9 @@ proc gdb_test_multiple { command message args } {
>   	}
>   	if { "$string" != "" } {
>   	    if { [send_gdb "$string"] != "" } {
> -		perror "Couldn't send $command to GDB."
> +		verbose -log "Couldn't send $command to GDB."
> +		unresolved $message
> +		return -1
>   	    }
>   	}
>       }