From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ZmwaOZ69gWbYxxUAWB0awg (envelope-from ) for ; Sun, 30 Jun 2024 16:18:38 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=PeV6l+PY; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id DAB261E0C3; Sun, 30 Jun 2024 16:18:38 -0400 (EDT) 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 B0D241E030 for ; Sun, 30 Jun 2024 16:18:36 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 312FF3832E5D for ; Sun, 30 Jun 2024 20:18:36 +0000 (GMT) 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 3F5173858C39 for ; Sun, 30 Jun 2024 20:18:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3F5173858C39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3F5173858C39 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719778695; cv=none; b=V1V2Cs50/sFOvOdfNI1pPStdcb6ckQfVHFyHA0wecIlnfuFtbpMhUsnRQfl9Cv3uEv3ZSVG6ZBCUNP8lZoo0ou0uMpPO9wMULug+mrID4Tk/YkS2koVW7LiJca8iUAiEje6zxmPxEGmXDlRQ683aA0s/BA+X4iq8s2dgMJw0mEo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719778695; c=relaxed/simple; bh=uxBb7Gv9gX9um5Y7dNt7MYUCoDN5Y8ChMtz6Gwz1gOo=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=wGLIQV65XFUvae4hMIV5RrqF0MT7LSk+tBccwf9NKMwMUR7eVGcO5STEol8ZkM6GnAN15zh9hYFnWOJLkDr26Vx1TKerI1knJf2j4GXWWe7hwyinWcsxaWlea4DduVQ3ttZIreC8x8L+zdcmW/bPw7Vx6kUmmxUlfYEMqoG5Wq0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1719778691; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Pz6CtGB8jmgXesWxQ2lm7z7maNlkd1DVJ4W8//mbPaQ=; b=PeV6l+PYrFe7ypzXmsXtwCphW+f4ExomiR7I1puSmOdIvSsTfm4UUuL1F3xzt7pp1kvr8W 85o5CJMCzH3y7CHkmsYYFRyFv/aFXg9mO9I6ieBqEhVES73QEPNLKKkc/vOIcEQEfpdYpM P8WBBXmq5Pb423az2HjFiWF+YWVhmG8= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-478-muoRdpMAMnmytBOvZoYB1g-1; Sun, 30 Jun 2024 16:18:08 -0400 X-MC-Unique: muoRdpMAMnmytBOvZoYB1g-1 Received: from mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 5707D195608A; Sun, 30 Jun 2024 20:18:07 +0000 (UTC) Received: from f40-zbm-amd (unknown [10.22.16.241]) by mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2921F19560A3; Sun, 30 Jun 2024 20:18:05 +0000 (UTC) Date: Sun, 30 Jun 2024 13:18:03 -0700 From: Kevin Buettner To: Tom de Vries Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] [gdb] Prune inferior after switching inferior Message-ID: <20240630131803.50b2450f@f40-zbm-amd> In-Reply-To: <20240304122120.27659-1-tdevries@suse.de> References: <20240304122120.27659-1-tdevries@suse.de> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.40 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.9 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_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org 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 Hi Tom, See my comments inline below... On Mon, 4 Mar 2024 13:21:20 +0100 Tom de Vries wrote: > Usually with test-case gdb.python/py-progspace-events.exp I get: > ... > (gdb) inferior 1^M > [Switching to inferior 1 [process 4116] (py-progspace-events)]^M > [Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 4116))]^M > 28 { /* Nothing. */ }^M > (gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1 > step^M > FreeProgspaceEvent: ^M > do_parent_stuff () at py-progspace-events.c:41^M > 41 ++global_var;^M > (gdb) PASS: gdb.python/py-progspace-events.exp: step > ... > > But occasionally I run into the following FAIL: > ... > (gdb) inferior 1^M > [Switching to inferior 1 [process 5199] (py-progspace-events)]^M > [Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 5199))]^M > 28 { /* Nothing. */ }^M > (gdb) FreeProgspaceEvent: ^M > FAIL: gdb.python/py-progspace-events.exp: inferior 1 (timeout) > ... > > This is caused by a race between the handling of an event, and the > "inferior 1" command. > > In the passing case, the event is handled first. During which prune_inferiors > is called, but it can't remove inferior 1, because it's still the current one. > > In the failing case, the "inferior 1" command is handled first. Then during > handling of the event, prune_inferiors is called, and it can remove inferior 1 > because it's no longer the current one. > > This looks like a test-case issue to me, but ISTM that we can do better: by > calling prune_inferiors asap, at the end of the "inferior 1" command, we > stabilize the moment when the inferior is removed: > ... > (gdb) inferior 1^M > [Switching to inferior 1 [process 5199] (py-progspace-events)]^M > [Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 5199))]^M > 28 { /* Nothing. */ }^M > FreeProgspaceEvent: ^M > (gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1 > ... > > Tested on x86_64-linux. > > PR gdb/31440 > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31440 > --- > gdb/inferior.c | 4 +++ > .../gdb.python/py-progspace-events.exp | 31 +++---------------- > 2 files changed, 9 insertions(+), 26 deletions(-) > > diff --git a/gdb/inferior.c b/gdb/inferior.c > index 5ff5eb98955..4e179f7fb80 100644 > --- a/gdb/inferior.c > +++ b/gdb/inferior.c > @@ -791,6 +791,10 @@ inferior_command (const char *args, int from_tty) > notify_user_selected_context_changed > (USER_SELECTED_INFERIOR); > } > + > + /* Switching current inferior may have made one of the inferiors > + prunable, so prune it. */ > + prune_inferiors (); > } > } > This seems reasonable to me. > diff --git a/gdb/testsuite/gdb.python/py-progspace-events.exp b/gdb/testsuite/gdb.python/py-progspace-events.exp > index 95e4ca8da0b..9dfc7573d40 100644 > --- a/gdb/testsuite/gdb.python/py-progspace-events.exp > +++ b/gdb/testsuite/gdb.python/py-progspace-events.exp > @@ -79,37 +79,16 @@ gdb_test "continue" \ > "\\\[Inferior $decimal \[^\r\n\]+ exited normally\\\]"] \ > "continue until inferior 2 exits" > > -gdb_test "inferior 1" "\\\[Switching to inferior 1 .*" > - > -# Step the inferior. During this process GDB will prune the now > +# Switch to inferior 1. During this process GDB will prune the now > # defunct inferior, which deletes its program space, which should > # trigger the FreeProgspaceEvent. > # > -# However, there is a slight problem. When the target is remote, and > -# GDB is accessing files using remote fileio, then GDB will attempt to > -# prune the inferior at a point in time when the remote target is > -# waiting for a stop reply. Pruning an inferior causes GDB to close > -# files associated with that inferior. > -# > -# In non-async mode we can't send fileio packets while waiting for a > -# stop reply, so the attempts to close files fails, and this shows up > -# as an error. > -# > -# As this error has nothing to do with the feature being tested here, > -# we just accept the error message, the important part is the > -# 'FreeProgspaceEvent' string, so long as that appears (just once) > -# then the test is a success. > -set warning_msg \ > - [multi_line \ > - "warning: cannot close \"\[^\r\n\]+\": Cannot execute this command while the target is running\\." \ > - "Use the \"interrupt\" command to stop the target" \ > - "and then try again\\."] > > -gdb_test "step" \ > +gdb_test "inferior 1" \ > [multi_line \ > - "^FreeProgspaceEvent.*: (?:\r\n$warning_msg)*" \ > - "do_parent_stuff \\(\\) at \[^\r\n\]+" \ > - "$decimal\\s+\[^\r\n\]+"] > + "\\\[Switching to inferior 1 .*" \ > + ".*" \ > + "FreeProgspaceEvent.*: "] It appears that you've removed a test here. I'm guessing that the removed test, "step", was being done in order to trigger the event, but now that the inferior is being pruned when switching inferiors, the event happens at that time. If this reasoning is correct, I think it'd be worth mentioning it in the commit log. Is it the case that the problem(s) mentioned in the removed comments have been fixed as well? Kevin