[PATCH] gdb/testsuite: relax pattern in new gdb.mi/mi-multi-commands.exp test

[PATCH] gdb/testsuite: relax pattern in new gdb.mi/mi-multi-commands.exp test

[Andrew Burgess via Gdb-patches]

I saw some failures in the test gdb.mi/mi-multi-commands.exp that I
added recently.  This test was added in commit:

  commit d08cbc5d3203118da5583296e49273cf82378042
  Date:   Wed Dec 22 12:57:44 2021 +0000

      gdb: unbuffer all input streams when not using readline

The failures I see only occurred when my machine was very heavily
loaded.

In this test I send multiple commands from dejagnu to gdb with a
single send_gdb call.  In a well behaving world what I want to happen
is that the gdb console sees both commands arrive and echos the text
of those commands.  Then gdb starts processing the first command,
prints the result, and then processes the second command, and prints
the result.

However, what I saw in my loaded environment was that only after
sending the two commands, only the first command was echoed to gdb's
terminal.  Then gdb started processing the first command, and started
to write the output.  Now, mixed in with the first command output, the
second command was echoed to gdb's terminal.  Finally, gdb would
finish printing the first command output, and would read and handle
the second command.

This mixing of command echoing with the first command output was
causing the test matching patterns to fail.

In this commit I change the command I use in the test from a CLI
command to an MI command, this reduces the number of lines of output
that come from the test, CLI commands sent through the MI interpreter
are echoed back like this:

  (gdb)
  set $a = "FIRST COMMAND"
  &"set $a = \"FIRST COMMAND\"\n"
  ^done
  (gdb)

While this is not the case for true MI command:

  (gdb)
  -data-evaluate-expression $a
  ^done,value="\"FIRST COMMAND\""
  (gdb)

Less output makes for simpler patterns to match against.

Next, when sending two command to gdb I was previously trying to spot
the output of the first command followed by the prompt with nothing
between.  This is not really needed, for the first command I can look
for just the ^done,value="\"FIRST COMMAND\"" string, then I can start
looking for the output of the second command.

So long as the second pattern matches up to the gdb prompt, then I can
be sure than nothing is left over in the expect buffer to muck up
later matches.

As to see the second command output gdb must have read in the second
command, the second command output never suffers from the corruption
that the first command output does.

Since making this change, I've not seen a failure in this test.
---
 gdb/testsuite/gdb.mi/mi-multi-commands.exp | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gdb/testsuite/gdb.mi/mi-multi-commands.exp b/gdb/testsuite/gdb.mi/mi-multi-commands.exp
index 767d1d0f679..12b1b482f9a 100644
--- a/gdb/testsuite/gdb.mi/mi-multi-commands.exp
+++ b/gdb/testsuite/gdb.mi/mi-multi-commands.exp
@@ -54,7 +54,7 @@ proc run_test { args } {
 	set cmd ""
 
 	# Create a command that is at least `i` characters long.
-	set first_cmd "print \$a"
+	set first_cmd "-data-evaluate-expression \$a"
 	while { [string length $first_cmd] < $i } {
 	    set first_cmd " $first_cmd"
 	}
@@ -69,7 +69,7 @@ proc run_test { args } {
 	set i [string length $first_cmd]
 	verbose -log "length of first command is $i"
 
-	set cmd "${first_cmd}\nprint \$b\n"
+	set cmd "${first_cmd}\n-data-evaluate-expression \$b\n"
 
 	# We need to call send_gdb ourselves here as gdb_test_multiple
 	# will try to send each line of the command separately (breaking
@@ -100,14 +100,14 @@ proc run_test { args } {
 	set seen_second_message false
 
 	gdb_test_multiple "" "look for first command output, command length $i" -prompt "$mi_gdb_prompt" {
-	    -re "(&\"print \\\$\[ab\]\\\\n\")\r\n(~\"\\\$$decimal = \\\\\"FIRST COMMAND\\\\\"\[^\r\n\]+\r\n\\^done\r\n$mi_gdb_prompt)" {
+	    -re "\\^done,value=\"\\\\\"FIRST COMMAND\\\\\"\"\r\n" {
 		pass $gdb_test_name
 		set seen_first_message true
 	    }
 	}
 
 	gdb_test_multiple "" "look for second command output, command length $i" -prompt "$mi_gdb_prompt" {
-	    -re "(&\"print \\\$\[ab\]\\\\n\")\r\n(~\"\\\$$decimal = \\\\\"TEST COMPLETE\\\\\"\[^\r\n\]+\r\n\\^done\r\n$mi_gdb_prompt)" {
+	    -re "\\^done,value=\"\\\\\"TEST COMPLETE\\\\\"\"\r\n$mi_gdb_prompt" {
 		pass $gdb_test_name
 		set seen_second_message true
 	    }
-- 
2.25.4

Re: [PATCH] gdb/testsuite: relax pattern in new gdb.mi/mi-multi-commands.exp test

[Andrew Burgess via Gdb-patches]

Andrew Burgess <aburgess@redhat.com> writes:

> I saw some failures in the test gdb.mi/mi-multi-commands.exp that I
> added recently.  This test was added in commit:
>
>   commit d08cbc5d3203118da5583296e49273cf82378042
>   Date:   Wed Dec 22 12:57:44 2021 +0000
>
>       gdb: unbuffer all input streams when not using readline
>
> The failures I see only occurred when my machine was very heavily
> loaded.

I have now pushed this patch.  I've run into these test failures a
couple more times, and it was getting annoying.  If anyone has any
feedback later, I'm happy to address it.

Thanks,
Andrew


>
> In this test I send multiple commands from dejagnu to gdb with a
> single send_gdb call.  In a well behaving world what I want to happen
> is that the gdb console sees both commands arrive and echos the text
> of those commands.  Then gdb starts processing the first command,
> prints the result, and then processes the second command, and prints
> the result.
>
> However, what I saw in my loaded environment was that only after
> sending the two commands, only the first command was echoed to gdb's
> terminal.  Then gdb started processing the first command, and started
> to write the output.  Now, mixed in with the first command output, the
> second command was echoed to gdb's terminal.  Finally, gdb would
> finish printing the first command output, and would read and handle
> the second command.
>
> This mixing of command echoing with the first command output was
> causing the test matching patterns to fail.
>
> In this commit I change the command I use in the test from a CLI
> command to an MI command, this reduces the number of lines of output
> that come from the test, CLI commands sent through the MI interpreter
> are echoed back like this:
>
>   (gdb)
>   set $a = "FIRST COMMAND"
>   &"set $a = \"FIRST COMMAND\"\n"
>   ^done
>   (gdb)
>
> While this is not the case for true MI command:
>
>   (gdb)
>   -data-evaluate-expression $a
>   ^done,value="\"FIRST COMMAND\""
>   (gdb)
>
> Less output makes for simpler patterns to match against.
>
> Next, when sending two command to gdb I was previously trying to spot
> the output of the first command followed by the prompt with nothing
> between.  This is not really needed, for the first command I can look
> for just the ^done,value="\"FIRST COMMAND\"" string, then I can start
> looking for the output of the second command.
>
> So long as the second pattern matches up to the gdb prompt, then I can
> be sure than nothing is left over in the expect buffer to muck up
> later matches.
>
> As to see the second command output gdb must have read in the second
> command, the second command output never suffers from the corruption
> that the first command output does.
>
> Since making this change, I've not seen a failure in this test.
> ---
>  gdb/testsuite/gdb.mi/mi-multi-commands.exp | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/gdb/testsuite/gdb.mi/mi-multi-commands.exp b/gdb/testsuite/gdb.mi/mi-multi-commands.exp
> index 767d1d0f679..12b1b482f9a 100644
> --- a/gdb/testsuite/gdb.mi/mi-multi-commands.exp
> +++ b/gdb/testsuite/gdb.mi/mi-multi-commands.exp
> @@ -54,7 +54,7 @@ proc run_test { args } {
>  	set cmd ""
>  
>  	# Create a command that is at least `i` characters long.
> -	set first_cmd "print \$a"
> +	set first_cmd "-data-evaluate-expression \$a"
>  	while { [string length $first_cmd] < $i } {
>  	    set first_cmd " $first_cmd"
>  	}
> @@ -69,7 +69,7 @@ proc run_test { args } {
>  	set i [string length $first_cmd]
>  	verbose -log "length of first command is $i"
>  
> -	set cmd "${first_cmd}\nprint \$b\n"
> +	set cmd "${first_cmd}\n-data-evaluate-expression \$b\n"
>  
>  	# We need to call send_gdb ourselves here as gdb_test_multiple
>  	# will try to send each line of the command separately (breaking
> @@ -100,14 +100,14 @@ proc run_test { args } {
>  	set seen_second_message false
>  
>  	gdb_test_multiple "" "look for first command output, command length $i" -prompt "$mi_gdb_prompt" {
> -	    -re "(&\"print \\\$\[ab\]\\\\n\")\r\n(~\"\\\$$decimal = \\\\\"FIRST COMMAND\\\\\"\[^\r\n\]+\r\n\\^done\r\n$mi_gdb_prompt)" {
> +	    -re "\\^done,value=\"\\\\\"FIRST COMMAND\\\\\"\"\r\n" {
>  		pass $gdb_test_name
>  		set seen_first_message true
>  	    }
>  	}
>  
>  	gdb_test_multiple "" "look for second command output, command length $i" -prompt "$mi_gdb_prompt" {
> -	    -re "(&\"print \\\$\[ab\]\\\\n\")\r\n(~\"\\\$$decimal = \\\\\"TEST COMPLETE\\\\\"\[^\r\n\]+\r\n\\^done\r\n$mi_gdb_prompt)" {
> +	    -re "\\^done,value=\"\\\\\"TEST COMPLETE\\\\\"\"\r\n$mi_gdb_prompt" {
>  		pass $gdb_test_name
>  		set seen_second_message true
>  	    }
> -- 
> 2.25.4