From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lndn.lancelotsix.com (vps-42846194.vps.ovh.net [IPv6:2001:41d0:801:2000::2400]) by sourceware.org (Postfix) with ESMTPS id D94FF3856263 for ; Tue, 2 Aug 2022 12:47:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D94FF3856263 Received: from octopus.. (unknown [IPv6:2a01:e0a:535:2750:1299:7061:a63:c92]) by lndn.lancelotsix.com (Postfix) with ESMTPSA id 0419F8980D; Tue, 2 Aug 2022 12:47:45 +0000 (UTC) From: Lancelot SIX To: gdb-patches@sourceware.org Cc: tdevries@suse.de, lsix@lancelotsix.com, Lancelot SIX Subject: [PATCH 1/2] gdb: Fix regression in varobj recreation Date: Tue, 2 Aug 2022 13:47:23 +0100 Message-Id: <20220802124724.284096-2-lancelot.six@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220802124724.284096-1-lancelot.six@amd.com> References: <20220802124724.284096-1-lancelot.six@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (lndn.lancelotsix.com [0.0.0.0]); Tue, 02 Aug 2022 12:47:46 +0000 (UTC) X-Spam-Status: No, score=-9.2 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_QUARANTINE, KAM_DMARC_STATUS, KHOP_HELO_FCRDNS, RCVD_IN_SBL_CSS, SPF_HELO_NONE, SPF_SOFTFAIL, 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: Tue, 02 Aug 2022 12:47:50 -0000 "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. 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. 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. */ -- 2.34.1