From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 9AB8E3858D37 for ; Mon, 21 Feb 2022 13:09:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9AB8E3858D37 Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-79-BOrqMCDNNG-ry3Lhfyv5BQ-1; Mon, 21 Feb 2022 08:09:55 -0500 X-MC-Unique: BOrqMCDNNG-ry3Lhfyv5BQ-1 Received: by mail-wm1-f69.google.com with SMTP id n26-20020a05600c3b9a00b0037c524e6d97so4432383wms.9 for ; Mon, 21 Feb 2022 05:09:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=FCPaqoRXb/EsmBypV833pAYnauv8waZLXW4CYKRKcdA=; b=5eMef3QuEn4CT4TYFS3bfdPS5joV/b3T1SvQ1+0uXBlnSI6DRq92TePgihpOPuOvZp zUKPjuLt1GLYRr5JWK3CFqV59oVLbUymmVKJnn7Caccl1U/IQTxdQSToTGO+ffF06Blv VFhNv+SN3J+wjOElD9spfEsxYGzN2fkJ67au873cFh0+rQJzgYAhuFwcG0amJoKIcRor UQMfjzSA59PdaVMEVvmS92hIRgQMUiTdAK73XmJq1VWXxW3xg8aHlpxMyFNSJeCMkMU5 im7sgwsKOp0gc9WIhh9lz/zDiijcaE5RpCt4AfJ0mg+ZDTHFall+hgg/DwQ52bRWPBt8 huHw== X-Gm-Message-State: AOAM530jKSVCHMZpNmxH1sTh3PTWC1gS7VpH/eCDzZmHvEBbAOjIsvlj dHwn1HVRunw5KrHvofyTe7ULVcmnbyISB1P3FqPEdVqgs2wO1yoYQ36AWxLyByuGzE9u2KxyzOT Lwu1xbYWpHrIuXFMng4NZxQQKuGuRqBsIHoCnSLYOoumTfvHW0ShQ1ji+IQA6BxmU9F0LWBFZQQ == X-Received: by 2002:a5d:4292:0:b0:1e4:b7fd:eb84 with SMTP id k18-20020a5d4292000000b001e4b7fdeb84mr15903328wrq.657.1645448993641; Mon, 21 Feb 2022 05:09:53 -0800 (PST) X-Google-Smtp-Source: ABdhPJxVEq3l1QsN1XHSOZhnqfFDWrN4wSdKfKPMuRYxBrjXPuefjJtcQcJIUD/GsP0fNKj/9P7z7g== X-Received: by 2002:a5d:4292:0:b0:1e4:b7fd:eb84 with SMTP id k18-20020a5d4292000000b001e4b7fdeb84mr15903307wrq.657.1645448993311; Mon, 21 Feb 2022 05:09:53 -0800 (PST) Received: from localhost (host86-169-131-29.range86-169.btcentralplus.com. [86.169.131.29]) by smtp.gmail.com with ESMTPSA id p8sm43657611wro.106.2022.02.21.05.09.52 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Feb 2022 05:09:52 -0800 (PST) From: Andrew Burgess To: gdb-patches@sourceware.org Subject: Re: [PATCH] gdb/testsuite: relax pattern in new gdb.mi/mi-multi-commands.exp test In-Reply-To: <20220210184433.3095152-1-aburgess@redhat.com> References: <20220210184433.3095152-1-aburgess@redhat.com> Date: Mon, 21 Feb 2022 13:09:52 +0000 Message-ID: <87ee3wcqn3.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2022 13:09:58 -0000 Andrew Burgess 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