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 A323D385842E for ; Tue, 22 Mar 2022 11:03:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A323D385842E Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-279-TZLfajMQMsSjq7Vo1omZEw-1; Tue, 22 Mar 2022 07:03:16 -0400 X-MC-Unique: TZLfajMQMsSjq7Vo1omZEw-1 Received: by mail-wm1-f72.google.com with SMTP id 4-20020a05600c274400b0038c8ab2e835so714676wmw.1 for ; Tue, 22 Mar 2022 04:03:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=vG4Js8ygNs4b3SSK6XuI4AaMG2IScvP7UbP5J9VaM1k=; b=ak0aPJ51LQs+lG5GiklGd4ZQbAqCdmL0CBn8Pb9pF0gYYNF/wbToUcDTnHeTYU4ZjP gvLNuD8/wCfVN1KtJzP/GCFXqSnOYdbsE+hoYkQyMuCW7DcjwguAU20toGaldTshOqCh Fc9tOIY7DTXjMwiCJXqXjTNRe+CxNqjpVB0UBOwu4U6iXM6scFf1cmiDkLLVaIx1ejME uxiOHBP9BCerX0Bg5/d+4yeE9zCQElxBEt5kFbNM2hGoRyfx5JQNbHIGvDS2FPNYdwmB Ra7sQXizDkopbqdVA3G0dt/j+sB+FsNLoDW6l8I8sm9pwrK/bxwnxB0E/BVjd53rv2aa fcHQ== X-Gm-Message-State: AOAM532CiDqqtWcSNbWo7X01afNrH7z7tpzQ+mRBS9+2a7ZKN1Bm/AJb Uwtuj+nBUvTTzerpCHFa8SrO35p/eWnvuGIK4x+4O3sMQxvGfU2qNCdx36UhLWf7YifnjIusn4R TSSkdU1n8RwHo5VB+QfgAj5etUZ2d1rBflRYjVMP74Zcm1monKIMj9wpXIxrj6/lv1ZimN2wrvQ == X-Received: by 2002:a05:600c:4608:b0:38c:6ba3:1c9f with SMTP id m8-20020a05600c460800b0038c6ba31c9fmr3202648wmo.39.1647946994395; Tue, 22 Mar 2022 04:03:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxGVWfdaK6iQ0Ri8Q9I710XZd0PxJ0GTNZX5gTPwsLC1Y5D+UNRnLMU9Utjj5t8J6zwiSV2yw== X-Received: by 2002:a05:600c:4608:b0:38c:6ba3:1c9f with SMTP id m8-20020a05600c460800b0038c6ba31c9fmr3202609wmo.39.1647946994032; Tue, 22 Mar 2022 04:03:14 -0700 (PDT) Received: from localhost (host109-158-45-15.range109-158.btcentralplus.com. [109.158.45.15]) by smtp.gmail.com with ESMTPSA id r15-20020a5d6c6f000000b002040552e88esm8914601wrz.29.2022.03.22.04.03.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Mar 2022 04:03:13 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCH] gdb/testsuite: address test failures in gdb.mi/mi-multi-commands.exp Date: Tue, 22 Mar 2022 11:03:09 +0000 Message-Id: <20220322110309.3831447-1-aburgess@redhat.com> X-Mailer: git-send-email 2.25.4 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII" X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, HEXHASH_WORD, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, 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: Tue, 22 Mar 2022 11:03:19 -0000 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 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" { } } -- 2.25.4