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.133.124]) by sourceware.org (Postfix) with ESMTPS id 46F673858C53 for ; Mon, 4 Apr 2022 09:03:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 46F673858C53 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-624-1727TBiUNgm6_JXXS_5G9A-1; Mon, 04 Apr 2022 05:03:24 -0400 X-MC-Unique: 1727TBiUNgm6_JXXS_5G9A-1 Received: by mail-wm1-f72.google.com with SMTP id r6-20020a05600c35c600b0038e6db5da9cso645229wmq.9 for ; Mon, 04 Apr 2022 02:03:24 -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:in-reply-to:references:date :message-id:mime-version; bh=nTJtKH4DAOJbLXIXgnkiLH+qVuVl/x4t1HW9v21KiLk=; b=uszy4dfPhgRd/W057wOTxAgmmDH5zsJjAx/kNAKGv7T0OrjYUDkAG1oFD1jtcgKS6N ZwRgopu2DwGNLy8B4I+BPeVc4CI2LhDZNduzsjD28gRxSYOQBEh5VZE5vqIyTlHk+l4Y xOMwsnXhnywHwFo7IQySingkeLY8mVF7Am+/kAqnOFR26BcO5qyyJ2bitJ/uyUDG6QzG ost0Rhy1HBG953TSrmunPQjaVg+J0n+vrGi7fXvCbzhT8qYOZacFkjDw8AebyUF2lhQr Zw4tQXB4uwuDYSLACyjHIuovFTKD98GHrGbl3v85mbnv3jaffPnuFhBODFgA+kW7gP8q WPMA== X-Gm-Message-State: AOAM532xAVMxvJAATDBeQrORh0bGMr6V4Oh1nkGs/Y2f8r8xwBSEbu/j LKkQojbQE3k8a+nbb1gYDXr+ur/o7dTUB2hbdx2IEv6XodQcfBdzhGbLqB0KamC+pNvXNCqyfXd w+6S2Ew0iCRgbjCjb5w9usbzSPpbg1vDAnseY9HC/JKPNpe+nnqTHWrrQQPvCNh5/cBGnGgJnQg == X-Received: by 2002:a5d:5964:0:b0:206:f29:4c5c with SMTP id e36-20020a5d5964000000b002060f294c5cmr4056440wri.45.1649063003443; Mon, 04 Apr 2022 02:03:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzbMKT9JkeglY0YiHTB8bHchwWNH0zeV/E3gzc6kpz263aw44JI8pkoYbvReGsz9U/nctajeA== X-Received: by 2002:a5d:5964:0:b0:206:f29:4c5c with SMTP id e36-20020a5d5964000000b002060f294c5cmr4056415wri.45.1649063003098; Mon, 04 Apr 2022 02:03:23 -0700 (PDT) Received: from localhost (host86-169-131-113.range86-169.btcentralplus.com. [86.169.131.113]) by smtp.gmail.com with ESMTPSA id h5-20020a5d5485000000b002060e2f1607sm3338672wrv.40.2022.04.04.02.03.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 02:03:22 -0700 (PDT) From: Andrew Burgess To: Simon Marchi via Gdb-patches , gdb-patches@sourceware.org Cc: Simon Marchi , Jan Vrany Subject: Re: [PATCH] gdb/testsuite: fix intermittent failure in gdb.mi/mi-cmd-user-context.exp In-Reply-To: <20220403190625.3381605-1-simon.marchi@efficios.com> References: <20220403190625.3381605-1-simon.marchi@efficios.com> Date: Mon, 04 Apr 2022 10:03:21 +0100 Message-ID: <8735it8bl2.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=-12.2 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, RCVD_IN_MSPIKE_H5, 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: Mon, 04 Apr 2022 09:03:27 -0000 Simon Marchi via Gdb-patches writes: > 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. All sounds reasonable. LGTM. Thanks, Andrew > > 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