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 C1FF0385734E for ; Thu, 28 Apr 2022 11:27:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C1FF0385734E Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-473-8oB1WUUYOniizeWqFrWpag-1; Thu, 28 Apr 2022 07:27:19 -0400 X-MC-Unique: 8oB1WUUYOniizeWqFrWpag-1 Received: by mail-wm1-f71.google.com with SMTP id r186-20020a1c44c3000000b00393f52ed5ceso3490819wma.7 for ; Thu, 28 Apr 2022 04:27:19 -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:in-reply-to :references:mime-version:content-transfer-encoding; bh=LJMlFUWmjhNPF51NzIEmBPGXVP/phL93a0KGaACmWoA=; b=bKShdNjAHY3BDVONDxMLUSQ10BvF9kt4c6SoRiBoOyfxbP+63ffsXMppAZV3KAPiq5 Tu4E4J3VmkbZySA7iKvuhV85FD3XHKQ15AMKXb35lqgkP2596gCviVpI+Hc0fl8Z3kcy tt7c7G7SemQcxgJZRxTsl5KpvmD8UIdVHjNMrHCqIpVH6s35dEbtermhzvgep0kpvEho OvL1xYlwW/yXWuot7Fmz3tk1Lc1MCjC3k9LcvvONf+LrGPktg3zNIhzo5kaK1BgszyBr nlXbAZ2UA6gd5lhB78z/3ddx7vjgbFZfPiuKtBqMadbULnRIAeMI3JYOVQiO/UvlbXVK B6jA== X-Gm-Message-State: AOAM532jtuVpzGIcwX4wlExIrIRoa71Kfv+V+ehxre4TcYJm09gaXj/y 8WghpCxUe85v82jLAf5lRq6/lM+jKE6LDSmT1KDXMd09zwg2H1pOYdIYjL18+XC2Yo8ZJ6D+rl2 UyYS27LfxeLYFgmy4b/nB7V3d+WbVq0QHIPBky7Sf8/8Y/mEq6MglmyKuUaA/l48TlUyp0zOpKA == X-Received: by 2002:a05:600c:502a:b0:394:1961:cbee with SMTP id n42-20020a05600c502a00b003941961cbeemr638792wmr.53.1651145237791; Thu, 28 Apr 2022 04:27:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx6jBW/1TAgpxeokujkqMmNsciFpS0dT1/wtwL/ptnVNByGNg9nGstxjCQtATVByKFKQTsiZg== X-Received: by 2002:a05:600c:502a:b0:394:1961:cbee with SMTP id n42-20020a05600c502a00b003941961cbeemr638770wmr.53.1651145237439; Thu, 28 Apr 2022 04:27:17 -0700 (PDT) Received: from localhost (host81-136-113-48.range81-136.btcentralplus.com. [81.136.113.48]) by smtp.gmail.com with ESMTPSA id w5-20020a7bc105000000b0038eb9932dacsm3639894wmi.48.2022.04.28.04.27.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Apr 2022 04:27:16 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCHv2 1/2] gdb: fix failures in gdb.mi/mi-exec-run.exp with native-extended-gdbserver Date: Thu, 28 Apr 2022 12:27:10 +0100 Message-Id: <6f0c6ff4f300d81bd063675913bd973cea652afd.1651145162.git.aburgess@redhat.com> X-Mailer: git-send-email 2.25.4 In-Reply-To: References: 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-default=true X-Spam-Status: No, score=-12.4 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 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: Thu, 28 Apr 2022 11:27:22 -0000 When running the gdb.mi/mi-exec-run.exp test using the native-extended-gdbserver I see failures like this: FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=main: force-fail=1: run failure detected FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=separate: force-fail=1: run failure detected FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=1: run failure detected There's a race condition here, so you might see a slightly different set of failures, but I always see some from the 'run failure detected' test. NOTE: I also see an additional test failure: FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=0: breakpoint hit reported on console (timeout) but that is a completely different issue, and is not being addressed in this commit. The problem for the 'run failure detected' test is that we end up in gdb_expect looking for output from two spawn-ids, one from gdbserver, and one from gdb. We're looking for one output pattern from each spawn-id, and for the test to pass we need to see both patterns. Now, if gdb exits then this is a test failure (this would indicate gdb crashing, which is bad), so we have an eof pattern associated with the gdb spawn-id. However, in this particular test we expect gdbserver to fail to execute the binary (the test binary is set non-executable), and so we get an error message from gdbserver (which matches the pattern), and then gdbserver exits, this is expected. The problem is that after spotting the pattern from gdbserver, we often see the eof from gdbserver before we see the pattern from gdb. If this happens then we drop out of the gdb_expect without ever seeing the pattern from gdb, and fail the test. In this commit, I place the spawn-id of gdbserver into a global variable, and then use this global variable as the -i option within the gdb_expect. Now, once we have seen the expected pattern on the gdbserver spawn-id, the global variable is cleared. After this the gdb_expect no longer checks the gdbserver spawn-id for additional output, and so never sees the eof event. This leaves the gdb_expect running, which allows the pattern from gdb to be seen, and for the test to pass. I now see no failures relating to 'run failure detected'. --- gdb/testsuite/gdb.mi/mi-exec-run.exp | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/gdb/testsuite/gdb.mi/mi-exec-run.exp b/gdb/testsuite/gdb.mi/mi-exec-run.exp index f397159078f..ffbe6bcd36e 100644 --- a/gdb/testsuite/gdb.mi/mi-exec-run.exp +++ b/gdb/testsuite/gdb.mi/mi-exec-run.exp @@ -93,10 +93,27 @@ proc test {inftty_mode mi_mode force_fail} { set test "run failure detected" send_gdb "-exec-run --start\n" + # Redirect through SPAWN_LIST global. If the + # inferior_spawn_id is not the same as gdb_spawn_id, e.g. when + # testing with gdbserver, the gdbserver can exit after + # emitting it's error message. + # + # If inferior_spawn_id exits then we may see the eof from that + # spawn-id before we see the pattern from the gdb_spawn_id, + # which will kick us out of the gdb_expect, and cause us to + # fail the test. + # + # Instead we clean SPAWN_LIST once we've seen the expected + # pattern from that spawn-id, and after that we no longer care + # when gdbserver exits. + global spawn_list + set spawn_list "$inferior_spawn_id" + gdb_expect { - -i "$inferior_spawn_id" + -i spawn_list -re ".*Cannot exec.*Permission denied" { set saw_perm_error 1 + set spawn_list "" verbose -log "saw perm error" if {!$saw_mi_error} { exp_continue -- 2.25.4