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 693C63858413 for ; Sun, 2 Oct 2022 17:05:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 693C63858413 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.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-210-y34ryelxOr2PPUbVb7IzvA-1; Sun, 02 Oct 2022 13:05:01 -0400 X-MC-Unique: y34ryelxOr2PPUbVb7IzvA-1 Received: by mail-wm1-f72.google.com with SMTP id r128-20020a1c4486000000b003b3309435a9so7085357wma.6 for ; Sun, 02 Oct 2022 10:05:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date; bh=HxhYM++0RjvJEu8CISnZW3K5C0pZi1gKg663mdTbMzw=; b=zDAXXxbhW/UTXqSPBtFf3/4DQvcOFqLG3jGFgKq8tUJmQXOcPokMsrt3nixVA2pBgq 8uWFNh5BTu2rBoKFrd0acJvyqFIykuVbgmwl8P//BIqBYpID/SgEBRx9tyYxHsMHSvdj A1kgD+3H6jrWsrkhwXNql9KhdmNjnNHUFtZCZMlIk52DrSxEMmrNcdE95Zp1l2rZzast zAzwNDdgg6EShkE3xrab+YvHcThWtCjywSVJM36dqakF9h2O3+SXwmdeq3iDfpeF8dMC M7WtPGrNQ1BL4XB/RlsO5E0285qNiT0kMaV6qANsIW0/bA96Hs2TGYWHNkyxxLhGqVad wh8Q== X-Gm-Message-State: ACrzQf09/13hd5+pAzUM9bJLD646ayOzcYFErAcwYrujPu+ivF9SmnyG RC+mdLeWWdGs1bxpGayxC9P7a0DTum8tamqK2Swnkj5+ao8eAlyxhfnEgGhJw3wOaGYTtytBr0N YYiB6TlYx+xwH2ehbPF3rYnrAn51eNfjcBBRtnDODGkdiQiissbiIYVN5HXTDeoFDmlq6b9y1ug == X-Received: by 2002:a05:600c:1910:b0:3b4:bb80:c95e with SMTP id j16-20020a05600c191000b003b4bb80c95emr4401796wmq.54.1664730300292; Sun, 02 Oct 2022 10:05:00 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5iLukubpIWZEtgaZyGhP7GuZFhtHB/aocPlR1f5/lnrcVrdicosQ9+jIMsrUU9RWC5jE2dXA== X-Received: by 2002:a05:600c:1910:b0:3b4:bb80:c95e with SMTP id j16-20020a05600c191000b003b4bb80c95emr4401784wmq.54.1664730300028; Sun, 02 Oct 2022 10:05:00 -0700 (PDT) Received: from localhost (52.72.115.87.dyn.plus.net. [87.115.72.52]) by smtp.gmail.com with ESMTPSA id j29-20020adfa55d000000b00228d6bc8450sm9576745wrb.108.2022.10.02.10.04.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Oct 2022 10:04:59 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Subject: [PATCHv2 5/7] gdb: ensure all targets are popped before an inferior is destructed Date: Sun, 2 Oct 2022 18:04:46 +0100 Message-Id: X-Mailer: git-send-email 2.25.4 In-Reply-To: References: <20220921131200.3983844-1-aburgess@redhat.com> 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=-10.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_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, 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.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2022 17:06:11 -0000 Now that the inferiors target_stack automatically manages target reference counts, we might think that we don't need to unpush targets when an inferior is deleted... ...unfortunately that is not the case. The inferior::unpush function can do some work depending on the type of target, so it is important that we still pass through this function. To ensure that this is the case, in this commit I've added an assert to inferior::~inferior that ensures the inferior's target_stack is empty (except for the ever present dummy_target). I've then added a pop_all_targets call to delete_inferior, otherwise the new assert will fire in, e.g. the gdb.python/py-inferior.exp test. --- gdb/inferior.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/gdb/inferior.c b/gdb/inferior.c index 2014bf926b7..a498b9d493c 100644 --- a/gdb/inferior.c +++ b/gdb/inferior.c @@ -70,6 +70,15 @@ inferior::~inferior () { inferior *inf = this; + /* Before the inferior is deleted, all target_ops should be popped from + the target stack, this leaves just the dummy_target behind. If this + is not done, then any target left in the target stack will be left + with an artificially high reference count. As the dummy_target is + still on the target stack then we are about to loose a reference to + that target, leaving its reference count artificially high. However, + this is not critical as the dummy_target is a singleton. */ + gdb_assert (m_target_stack.top ()->stratum () == dummy_stratum); + m_continuations.clear (); target_desc_info_free (inf->tdesc_info); } @@ -231,6 +240,12 @@ delete_inferior (struct inferior *inf) gdb::observers::inferior_removed.notify (inf); + /* Pop all targets now, this ensures that inferior::unpush is called + correctly. As pop_all_targets ends up making a temporary switch to + inferior INF then we need to make this call before we delete the + program space, which we do below. */ + inf->pop_all_targets (); + /* If this program space is rendered useless, remove it. */ if (inf->pspace->empty ()) delete inf->pspace; -- 2.25.4