public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@redhat.com>
To: gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb/testsuite: relax pattern in new gdb.mi/mi-multi-commands.exp test
Date: Mon, 21 Feb 2022 13:09:52 +0000	[thread overview]
Message-ID: <87ee3wcqn3.fsf@redhat.com> (raw)
In-Reply-To: <20220210184433.3095152-1-aburgess@redhat.com>

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


      reply	other threads:[~2022-02-21 13:09 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-10 18:44 Andrew Burgess
2022-02-21 13:09 ` Andrew Burgess [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ee3wcqn3.fsf@redhat.com \
    --to=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).