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
prev parent 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).