From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id +gywAjcm6WK/GB8AWB0awg (envelope-from ) for ; Tue, 02 Aug 2022 09:27:19 -0400 Received: by simark.ca (Postfix, from userid 112) id EEF631EA05; Tue, 2 Aug 2022 09:27:18 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=snqTBU68; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_DYNAMIC, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (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 simark.ca (Postfix) with ESMTPS id 85D3C1E9EB for ; Tue, 2 Aug 2022 09:27:18 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BDE293852765 for ; Tue, 2 Aug 2022 13:27:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BDE293852765 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1659446837; bh=HoWG78qsSSvb51Rzgk5s7AdWM+8FlcnAQkgIfFPjsm8=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=snqTBU68PqFEcnfnmmC/3lcFAeau7OiN7+izPeKx0tRFkLAcuAJmtM3nItmvIZ8kj Ms31IIcPH6tTvXt69LFGt5J3ShrQJc7kOdNSZ9FyNFHtxAORPXK9aAG2tXje7V8+AJ hPiz6IGw6qzr7rga9nZbdvkk6+A3rCd0zvnswkRQ= Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 920E93856242 for ; Tue, 2 Aug 2022 13:26:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 920E93856242 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 98B571FECD; Tue, 2 Aug 2022 13:26:55 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 80BD21345B; Tue, 2 Aug 2022 13:26:55 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 2RoeHh8m6WJpWQAAMHmgww (envelope-from ); Tue, 02 Aug 2022 13:26:55 +0000 Message-ID: Date: Tue, 2 Aug 2022 15:26:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH 1/2] gdb: Fix regression in varobj recreation Content-Language: en-US To: Lancelot SIX , gdb-patches@sourceware.org References: <20220802124724.284096-1-lancelot.six@amd.com> <20220802124724.284096-2-lancelot.six@amd.com> In-Reply-To: <20220802124724.284096-2-lancelot.six@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: , From: Tom de Vries via Gdb-patches Reply-To: Tom de Vries Cc: lsix@lancelotsix.com Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 8/2/22 14:47, Lancelot SIX wrote: > "bc20e562ec0 gdb/varobj: Fix use after free in varobj" introduced a I'd do: ... Commit bc20e562ec0 "gdb/varobj: Fix use after free in varobj" introduced a ... in other words, start the line with a word rather than a git hash, and do the quoting around "$subject". [ Alternatively, you can use the 'fixes' style: ... Commit bc20e562ec0 ("gdb/varobj: Fix use after free in varobj") introduced a ... ] > regression. This commit makes sure that the varobj object does not > keeps stall references to object being freed when we unload an objfile. stall -> stale > This includes the "valid_block" field which is reset to nullptr if the > pointed to block is tied to an objfile being freed. > > However, at some point varobj_invalidate_iter might try to recreate > varobjs tracking either floating or globals. Varobj tracking globals > are identified as having the "valid_block" field set nullptr, but as > bc20e562ec0 might clear this field, we have lost the ability to > distinguish between varobj referring to globals and non globals. > > Fix this by introducing a "global" flag which tracks if a given varobj > was initially created as tracking a global. > LGTM. Thanks, - Tom > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29426 > --- > gdb/varobj.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/gdb/varobj.c b/gdb/varobj.c > index e558794617a..0683af1991e 100644 > --- a/gdb/varobj.c > +++ b/gdb/varobj.c > @@ -102,6 +102,9 @@ struct varobj_root > to symbols that do not exist anymore. */ > bool is_valid = true; > > + /* Set to true if the varobj was created as tracking a global. */ > + bool global = false; > + > /* Language-related operations for this variable and its > children. */ > const struct lang_varobj_ops *lang_ops = NULL; > @@ -336,6 +339,8 @@ varobj_create (const char *objname, > var->format = variable_default_display (var.get ()); > var->root->valid_block = > var->root->floating ? NULL : tracker.block (); > + var->root->global > + = var->root->floating ? false : var->root->valid_block == nullptr; > var->name = expression; > /* For a root var, the name and the expr are the same. */ > var->path_expr = expression; > @@ -2359,7 +2364,7 @@ static void > varobj_invalidate_iter (struct varobj *var) > { > /* global and floating var must be re-evaluated. */ > - if (var->root->floating || var->root->valid_block == nullptr) > + if (var->root->floating || var->root->global) > { > struct varobj *tmp_var; > > @@ -2375,7 +2380,7 @@ varobj_invalidate_iter (struct varobj *var) > varobj_delete (var, 0); > install_variable (tmp_var); > } > - else if (!var->root->floating) > + else if (var->root->global) > { > /* Only invalidate globals as floating vars might still be valid in > some other frame. */