From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by sourceware.org (Postfix) with ESMTPS id 960EF385842E for ; Tue, 22 Mar 2022 11:41:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 960EF385842E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f46.google.com with SMTP id r7so10548010wmq.2 for ; Tue, 22 Mar 2022 04:41:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=RN9nsQiZBIkK20r570HHknKmgdeuVmW/U+JSuK41DBY=; b=V1wMWVvZYohjylTey3majfldXgXvGrLCYSSS/7Ftra8ZEx2EG5d4fT7rMNO+VFjDfd uVpDPu70zADNUmraZPyQXs/zm35srR9fw3NQuJ8YCryng2XbqGWH6xvy0rSlY5NOzdSv Pnl5rNHptV05o6mkBI3POK6pdcSOGiKMRbRPbpML0jFdE5TsydO0wmmn6qYsTwPYsnVn VwZFByE/LTMqTJZczrcz+zNOEUTv1RKtN9ajLtiZhgZ1Fa0GXvs1UirzfRQNfs2sX3Oj Cjj4IiwXLak0ziLPN0tRJl7HnofDDWdd0EGIpB5X4wan9XBP/yyKCPCKF5ZNMr4fNnpy qtXw== X-Gm-Message-State: AOAM532i4fydctSFxR4Wc4IjhURlDmLj+2XIQuSXGUfKx71nMft4aV9m LIGPXjpIJBJLYD/UZEtR/+c= X-Google-Smtp-Source: ABdhPJym/h4bBfNXBKd69udh1KfGCdPwCzbztA8Bz8HdKUOJEvqtRLkp5B9lma3tblGcmMNU+XDfiA== X-Received: by 2002:a5d:6d52:0:b0:1f0:73eb:23b9 with SMTP id k18-20020a5d6d52000000b001f073eb23b9mr21597225wri.649.1647949263648; Tue, 22 Mar 2022 04:41:03 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id c5-20020a5d63c5000000b002040822b680sm10556160wrw.81.2022.03.22.04.41.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Mar 2022 04:41:02 -0700 (PDT) Message-ID: <10858fef-c04d-d67f-7fd4-6dbbd9b1d126@palves.net> Date: Tue, 22 Mar 2022 11:41:01 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH] gdb/testsuite: address test failures in gdb.mi/mi-multi-commands.exp Content-Language: en-US To: Andrew Burgess , gdb-patches@sourceware.org References: <20220322110309.3831447-1-aburgess@redhat.com> From: Pedro Alves In-Reply-To: <20220322110309.3831447-1-aburgess@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-9.7 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, 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: Tue, 22 Mar 2022 11:41:06 -0000 On 2022-03-22 11:03, Andrew Burgess via Gdb-patches wrote: > The gdb.mi/mi-multi-commands.exp 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 > > And then tweaked in commit: > > commit 144459531dd68a1287905079aaa131b777a8cc82 > Date: Mon Feb 7 20:35:58 2022 +0000 > > gdb/testsuite: relax pattern in new gdb.mi/mi-multi-commands.exp test > > The second of these commits was intended to address periodic test > failures that I was seeing, and this change did fix some problems, > but, unfortunately, introduced other issues. > > The problem is that the test relies on sending two commands to GDB in > a single write. As the characters that make these two commands arrive > they are echoed to GDB's console. However, there is a race between > how quickly the characters are echoed and how quickly GDB decides to > act on the incoming commands. > > Usually, both commands are echoed in full before GDB acts on the first > command, but sometimes this is not the case, and GDB can execute the > first command before both commands are fully echoed to the console. > In this case, the output of the first command will be mixed in with > the echoing of the second command. > > This mixing of the command echoing and the first command output is > what was causing failures in the original version of the test. > > The second commit relaxed the expected output pattern a little, but > was still susceptible to failures, so this commit further relaxes the > pattern. > > Now, we look for the first command output with no regard to what is > before, or after the command. Then we look for the fist mi prompt to fist -> first > indicate that the first command has completed. > > I believe that this change should make the test more stable than it > was before. > --- > gdb/testsuite/gdb.mi/mi-multi-commands.exp | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/gdb/testsuite/gdb.mi/mi-multi-commands.exp b/gdb/testsuite/gdb.mi/mi-multi-commands.exp > index 12b1b482f9a..22b0ccf9aaa 100644 > --- a/gdb/testsuite/gdb.mi/mi-multi-commands.exp > +++ b/gdb/testsuite/gdb.mi/mi-multi-commands.exp > @@ -100,9 +100,12 @@ 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 "\\^done,value=\"\\\\\"FIRST COMMAND\\\\\"\"\r\n" { > + -re "\\^done,value=\"\\\\\"FIRST COMMAND\\\\\"\"" { > pass $gdb_test_name > set seen_first_message true > + exp_continue > + } > + -re "\r\n$mi_gdb_prompt" { > } Should move the "pass" to the mi_gdb_prompt match too, otherwise if the prompt match ever fails, then as is this results in a PASS and then, say, a "FAIL ... (timeout)" for the same test. IIUC, should make the pass conditional on seen_first_message too: -re "\r\n$mi_gdb_prompt" { gdb_assert $seen_first_message $gdb_test_message }