From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from barracuda.ebox.ca (barracuda.ebox.ca [96.127.255.19]) by sourceware.org (Postfix) with ESMTPS id 729033858D37 for ; Sun, 3 Apr 2022 19:06:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 729033858D37 X-ASG-Debug-ID: 1649012786-0c856e06abaaf6f0001-fS2M51 Received: from smtp.ebox.ca (smtp.ebox.ca [96.127.255.82]) by barracuda.ebox.ca with ESMTP id vzqeQGhPUGIWJ4pn (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 03 Apr 2022 15:06:26 -0400 (EDT) X-Barracuda-Envelope-From: simon.marchi@efficios.com X-Barracuda-RBL-Trusted-Forwarder: 96.127.255.82 Received: from epycamd.internal.efficios.com (192-222-180-24.qc.cable.ebox.net [192.222.180.24]) by smtp.ebox.ca (Postfix) with ESMTP id 4F05A441D64; Sun, 3 Apr 2022 15:06:26 -0400 (EDT) From: Simon Marchi X-Barracuda-RBL-IP: 192.222.180.24 X-Barracuda-Effective-Source-IP: 192-222-180-24.qc.cable.ebox.net[192.222.180.24] X-Barracuda-Apparent-Source-IP: 192.222.180.24 To: gdb-patches@sourceware.org Cc: Jan Vrany , Simon Marchi Subject: [PATCH] gdb/testsuite: fix intermittent failure in gdb.mi/mi-cmd-user-context.exp Date: Sun, 3 Apr 2022 15:06:25 -0400 X-ASG-Orig-Subj: [PATCH] gdb/testsuite: fix intermittent failure in gdb.mi/mi-cmd-user-context.exp Message-Id: <20220403190625.3381605-1-simon.marchi@efficios.com> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: smtp.ebox.ca[96.127.255.82] X-Barracuda-Start-Time: 1649012786 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://96.127.255.19:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ebox.ca X-Barracuda-Scan-Msg-Size: 3390 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=8.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.97106 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Spam-Status: No, score=-3498.8 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_SOFTFAIL, 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: Sun, 03 Apr 2022 19:06:40 -0000 I got failures like this once on a CI: frame^M &"frame\n"^M ~"#0 child_sub_function () at /home/jenkins/workspace/binutils-gdb_master_build/arch/amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:33\n"^M ~"33\t dummy = !dummy; /* thread loop line */\n"^M ^done^M (gdb) ^M FAIL: gdb.mi/mi-cmd-user-context.exp: frame 1 (unexpected output) The problem is that the test expects the following regexp: ".*#0 0x.*" And that typically works, when the output of the frame command looks like: #0 0x00005555555551bb in child_sub_function () at ... My theory is the following. Whether or not the hexadecimal address is printed (roughly) depends on whether the current PC is at the beginning of a line. So depending on where thread 2 was when GDB stopped it (after thread 1 hit its breakpoint), we can get either output. Strangely, I couldn't reproduce the failure by running the test in a loop for a while. Given that the loop in child_sub_function compiles to just 6 instructions here, it should happen relatively often that GDB ptrace stops the thread when it's on one of the instructions that wouldn't print the hex. That remains a mystery. I'm still confident enough that this is the reason, so adjust the regexps to not expect an hexadecimal prefix (0x) but a function name instead (either child_sub_function or child_function). That one is always printed, and is also a good check that we are in the frame we expect. Note that for test "frame 5", we are showing a pthread frame (on my system), so the function name is internal to pthread, not something we can rely on. In that case, it's almost certain that we are not at the beginning of a line, or that we don't have debug info, so I think it's fine to expect the hex prefix. And for test "frame 6", it's ok to _not_ expect a hex prefix (what the test currently does), since we are showing thread 1, which has hit a breakpoint placed at the beginning of a line. Change-Id: I919673bbf9927158beb0e8b7e9e980b8d65eca90 --- gdb/testsuite/gdb.mi/mi-cmd-user-context.exp | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/gdb/testsuite/gdb.mi/mi-cmd-user-context.exp b/gdb/testsuite/gdb.mi/mi-cmd-user-context.exp index d7417d5ea7c..592e7b600da 100644 --- a/gdb/testsuite/gdb.mi/mi-cmd-user-context.exp +++ b/gdb/testsuite/gdb.mi/mi-cmd-user-context.exp @@ -79,7 +79,7 @@ mi_gdb_test "thread" \ # Check we're in frame 0. mi_gdb_test "frame" \ - ".*#0 0x.*" \ + ".*#0 .*child_sub_function .*" \ "frame 1" # Ask about a different frame in the current thread, the current frame @@ -93,7 +93,7 @@ mi_gdb_test "thread" \ "info thread 6" mi_gdb_test "frame" \ - ".*#0 0x.*" \ + ".*#0 .*child_sub_function.*" \ "frame 2" @@ -108,7 +108,7 @@ mi_gdb_test "thread" \ "info thread 7" mi_gdb_test "frame" \ - ".*#0 0x.*" \ + ".*#0 .*child_sub_function.*" \ "frame 3" # Select a different frame in the current thread. Despite the use of @@ -123,7 +123,7 @@ mi_gdb_test "thread" \ "info thread 8" mi_gdb_test "frame" \ - ".*#1 0x.*" \ + ".*#1 .*child_function.*" \ "frame 4" # Similar to the previous test, but this time the --frame option is -- 2.35.1