From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id sAZ9K4syK2g2NyoAWB0awg (envelope-from ) for ; Mon, 19 May 2025 09:30:51 -0400 Received: by simark.ca (Postfix, from userid 112) id AEB781E11C; Mon, 19 May 2025 09:30:51 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-9.0 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED, RCVD_IN_VALIDITY_RPBL,RCVD_IN_VALIDITY_SAFE autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 50B631E102 for ; Mon, 19 May 2025 09:30:51 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 00FC03858D20 for ; Mon, 19 May 2025 13:30:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 00FC03858D20 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) by sourceware.org (Postfix) with ESMTPS id 6737E3858C31 for ; Mon, 19 May 2025 13:23:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6737E3858C31 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6737E3858C31 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.221.49 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1747660996; cv=none; b=HG8KmJeXC85pZKavnzJGWgxbuXddmqoVthwoXN2QViQ7PyD4oyOPBgnHZbv6XtDBtqf9ItZ6o9y+rkgzqUIOqM1xXQRQnJ+Gnw/09kKbkw94ZyDJUpniWMywHFN7A8G4O0RLoH2PKosd44dwoOsBMknFDjl48AlvFJPXVqpq8Js= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1747660996; c=relaxed/simple; bh=6U9GcRuMyvtMmi7mnWU3mNZQfCKoZstOvvxJGNZ2QTk=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=FzXxYCDC6IsUjnLC+gpxtvhigTZGZDZcTmlerH/XQvTC8RmgZslh3dpLEZXpcdbNxbojaZOejLWwioFlM5M1Faf5TAl2aO7c3fwfCVvBLBYhMcZuFcACnexghwJFnYJaPfWqXY7w6AzkK1pRObIgPLgjl5I+KnD5oi9mGWh7qE8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6737E3858C31 Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-3a36e090102so612297f8f.2 for ; Mon, 19 May 2025 06:23:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747660995; x=1748265795; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wbGfunp9ci8yKclTkq0TwJ+dlb2cbiPSuEaEx1FJJEw=; b=NopkFJKciHoMjBakfaM7ie6RipARyYc4/PLZm095jFOYo7FljZcLlJHJ+v4qR9rTVQ 8bPubuAhbfs9tCijUw5buMjTK5OrGhYxKy5b7AzfodwDF3E/7+S9Vhjs2zmX+DPj/R28 5nEV7tUBOi4FE+dCI0ycSM/grtzqQNOzuaITWNguTXWIZO+BIe7mkVZ4QNu8JgvuYzaG liTj+OkMH1SoIMKUrIEGW96MixRBslYET6CdsdtvB1vBKFmxoPSM7pU/WwnkPUJSuFv/ Hyd47Yc2BXSbAOix/X2VUlOjCM0GdFRed+S9D6ORBhnd8aqaVrJp7/jbVByozuemQCPp /kWA== X-Gm-Message-State: AOJu0Yw9UI48NLyLF4O4Jiy6sUM1FZ2fJbpaJflVpCBmErALL57IFi/I VgUNJErHM+ajx3eVXHSN8QmworgoY7RTtAKuJnZ7xsVr5xL2PdRXRqXPUa/GCXQA X-Gm-Gg: ASbGncs6G2rWdm3w/DdloHrJE8CrvO72f/Y0OyP2iA6YYljq1PimWo7D87bxo3oRp1a pUoXXExW9Hrj6glybMApgVJqdx9sd8WFQ6En3YYy2OGtsVJcjTMP5yWWjKeQ+np72ggjrS0Kv4c vB90tBrTI4wjqhVZOZvJP/NVlYRhdP9L8vgqor+8bfFaIUmjkvvsV1iwyszRbZ1zCYycge/Smmg f5yTepsKUfL1fHj9roUzLBfWO+ENyNK2a7Vvlhe6N9u+rB79dmzUQngQMFrP2j4Evjl2mX3Ll8R 2DJMNqesyz8a7A4skq4qAiK2Dq4qnmbYIjorwAWYXRZrSCew0/0= X-Google-Smtp-Source: AGHT+IE+r0juxcwCdem8p/2fOxLd2ChQebH1yksPrbhwpSPjuh+S4GuyYrxo9S4tfaXvCNdFNLZpDg== X-Received: by 2002:a05:6000:40d9:b0:3a3:4b8a:9a36 with SMTP id ffacd0b85a97d-3a35c808b92mr11522420f8f.11.1747660994866; Mon, 19 May 2025 06:23:14 -0700 (PDT) Received: from localhost ([2001:8a0:4fe9:b400:8d90:6f0d:36bf:32df]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-3a369140048sm8210890f8f.57.2025.05.19.06.23.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 May 2025 06:23:14 -0700 (PDT) From: Pedro Alves To: gdb-patches@sourceware.org Subject: [PATCH v2 01/47] Make default_gdb_exit resilient to failed closes Date: Mon, 19 May 2025 14:22:22 +0100 Message-ID: <20250519132308.3553663-2-pedro@palves.net> X-Mailer: git-send-email 2.49.0 In-Reply-To: <20250519132308.3553663-1-pedro@palves.net> References: <20250519132308.3553663-1-pedro@palves.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org For some reason, when testing GDB on Cygwin, I get: child process exited abnormally while executing "exec sh -c "exec > /dev/null 2>&1 && (kill -2 -$spid || kill -2 $spid)"" (procedure "close_wait_program" line 20) invoked from within "close_wait_program $shell_id $pid" (procedure "standard_close" line 23) invoked from within "standard_close "Windows-ROCm"" ("eval" body line 1) invoked from within "eval ${try}_${proc} \"$dest\" $args" (procedure "call_remote" line 42) invoked from within "call_remote "" close $host" (procedure "remote_close" line 3) invoked from within "remote_close host" (procedure "log_and_exit" line 30) invoked from within "log_and_exit" When that happens from within clean_restart, clean_restart doesn't clear the gdb_spawn_id variable, and then when clean_restart starts up a new GDB, that sees that gdb_spawn_id is already set, so it doesn't actually spawn a new GDB, and so clean_restart happens to reuse the same GDB (!). Many tests happen to actually work OK with this, but some don't, and the failure modes can be head-scratching. Of course, the failure to close GDB should be fixed, but when it happens, I think it's good to not end up with the current weird state. Connecting the "child process exit abnormally" errors at the end of a testcase run with weird FAILs in other testcases took me a while (as in, weeks!), it wasn't obvious to me immediately. Thus, this patch makes default_gdb_exit more resilient to failed closes, so that gdb_spawn_id is unset even is closing GDB fails, and we move on to start a new GDB. Change-Id: I9ec95aa61872a40095775534743525e0ad2097d2 --- gdb/testsuite/lib/gdb.exp | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index 49ef0d54654..c51cea86a9d 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -2315,7 +2315,9 @@ proc default_gdb_exit {} { } if ![is_remote host] { - remote_close host + if {[catch { remote_close host } message]} { + warning "closing gdb failed with: $message" + } } unset gdb_spawn_id unset ::gdb_tty_name -- 2.49.0