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 D022E3858039 for ; Thu, 24 Feb 2022 17:41:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D022E3858039 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-94-u9yrn_t6NxSocWuzSaV3Fg-1; Thu, 24 Feb 2022 12:41:15 -0500 X-MC-Unique: u9yrn_t6NxSocWuzSaV3Fg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 980FE100C611 for ; Thu, 24 Feb 2022 17:41:14 +0000 (UTC) Received: from guittard.redhat.com (unknown [10.2.17.55]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2ECB01077D1F for ; Thu, 24 Feb 2022 17:41:13 +0000 (UTC) From: Keith Seitz To: gdb-patches@sourceware.org Subject: [PATCH] Fix "spawn id XYZ not open" errors in gdb.mi/mi-exec-run.exp Date: Thu, 24 Feb 2022 09:41:13 -0800 Message-Id: <20220224174113.1620498-1-keiths@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 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=-12.6 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: Thu, 24 Feb 2022 17:41:19 -0000 Running mi-exec-run.exp on native-extended-gdbserver/-m{32,64} causes several Tcl errors to appear. For example, (gdb) ERROR: : spawn id exp20 not open while executing "expect { -i exp11 -timeout 10 -i "$inferior_spawn_id" -re ".*Cannot exec.*Permission denied" { set saw_perm_error 1 verbose -log "saw..." ("uplevel" body line 1) invoked from within "uplevel $body" NONE : spawn id exp20 not open UNRESOLVED: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=1: run failure detected (eof) This is happening because of the way this test is implemented: while {1} { gdb_expect { -i "$inferior_spawn_id" -re ".*Cannot exec.*Permission denied" { set saw_perm_error 1 verbose -log "saw mi error" } -i "$gdb_spawn_id" -re "\\^error,msg=\"During startup program exited with code 127" { set saw_mi_error 1 verbose -log "saw mi error" } # and so on } } The first time this loop is executed, `inferior_spawn_id' is valid. When the first branch of the expect statement is reached, gdbserver has exited, closing the spawn_id. Since we haven't seen the gdb-side error yet, the loop is executed again. The first branch now refers to a non-existent spawn_id, leading to the error. This can be fixed by using exp_continue to loop in expect instead of looping around expect, which is the approach I have used[1]. Note I've had to update the expected message for the "During startup..." error message when running with gdbserver. One other small change I've made is to add a log entry which spills the values of the two variables, saw_mi_error and saw_perm_error (and updated the log output for the later). This should make the log output clearer about why the test failed. With this patch installed, all the ERRORs disappear, leaving previously masked FAILs (which I have not attempted to fix). [1] Anyone know why this test doesn't simply use gdb_test_multiple? I can only assume that it was intentionally written this way, and I've modified the code with that assumption. I have tested a version using gdb_test_multiple, and that appears to work fine, too, if that is preferred. [It still employs exp_continue to fix the spawn_id errors.] --- gdb/testsuite/gdb.mi/mi-exec-run.exp | 53 ++++++++++++++++------------ 1 file changed, 30 insertions(+), 23 deletions(-) diff --git a/gdb/testsuite/gdb.mi/mi-exec-run.exp b/gdb/testsuite/gdb.mi/mi-exec-run.exp index eaf7dfa68bf..f397159078f 100644 --- a/gdb/testsuite/gdb.mi/mi-exec-run.exp +++ b/gdb/testsuite/gdb.mi/mi-exec-run.exp @@ -89,36 +89,43 @@ proc test {inftty_mode mi_mode force_fail} { if {$force_fail} { set saw_perm_error 0 set saw_mi_error 0 + set already_failed 0 set test "run failure detected" send_gdb "-exec-run --start\n" - while {1} { - gdb_expect { - -i "$inferior_spawn_id" - -re ".*Cannot exec.*Permission denied" { - set saw_perm_error 1 - verbose -log "saw mi error" + gdb_expect { + -i "$inferior_spawn_id" + -re ".*Cannot exec.*Permission denied" { + set saw_perm_error 1 + verbose -log "saw perm error" + if {!$saw_mi_error} { + exp_continue } - -i "$gdb_spawn_id" - -re "\\^error,msg=\"During startup program exited with code 127" { - set saw_mi_error 1 - verbose -log "saw mi error" - } - timeout { - fail "$test (timeout)" - break - } - -i "$gdb_main_spawn_id" - eof { - fail "$test (eof)" - break + } + -i "$gdb_spawn_id" + -re "\\^error,msg=\"(During startup program exited with code 127|Running .* on the remote target failed)" { + set saw_mi_error 1 + verbose -log "saw mi error" + if {!$saw_perm_error} { + exp_continue } } - - if {$saw_perm_error && $saw_mi_error} { - pass $test - break + timeout { + set already_failed 1 + fail "$test (timeout)" } + -i "$gdb_main_spawn_id" + eof { + set already_failed 1 + fail "$test (eof)" + } + } + + if {$saw_perm_error && $saw_mi_error} { + pass $test + } elseif {!$already_failed} { + verbose -log "saw_perm_error=$saw_perm_error; saw_mi_error=$saw_mi_error" + fail $test } } else { mi_run_cmd "--start" -- 2.34.1