From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2053.outbound.protection.outlook.com [40.107.223.53]) by sourceware.org (Postfix) with ESMTPS id 327C33851AB1 for ; Mon, 20 Jun 2022 17:19:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 327C33851AB1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bZWJpdUok9gMDQCpwVz9XWABq5RHxF08HmFyOYmRHXPbhNg+BlVP4smX7qa48dMSttIEqHZWUbPUD1BNckR1Z87pzZj3gnG9pTQqpX1a2eQRhlbRcvNxVGcvTtv05ExvtKApd1ZDd9SAr6MmeegJeCRfhqcYIjnL7UTJT7wxWF7MT+UlTVKkbWGxYG7IAoiu48p12/uj+uxM7TigqF8g6llylegjyy3xswyGDkGT/UzQGqjTBjbPlyEiBZCEw4pNTYjxXE/csyyw6x7JqSG40k1VXth8CQt/ZQLtLSEy5/tWu9rsB3bqatzjbuHTnbhiB2ef7JwcBSJOgzDNp5uCbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=p8Jrbnjf6ysz0/WB363iP7Vna04csyUl3JlbR4cBWYQ=; b=MyOmhZnWTrCF566M8a/wyJ41EQ4WskmRb3z75lvQiky8wlSe6PlNC111/OlGhXLue0aNy+hqpPFlMd8B0PnFXlxNFUxL3bZR0iu+CGAtDbWKMswrd+xVI1lyfY6hc/ddZRkpRLMmrNvY517WJlax4K8/yClLVpYm24MyH/ArvLKPI4Hv8ubQN4FgR3o5m+P6Kln/PsBrw3u+RP6P3zplGO+Gu7Df01Yldj/g5paoEbick+o6FLRZnfX1uaM6VgvmkwWnOxH4k9dTdUuZ21GRDX4LlmMDEvPOYgqszlN07lYMkLWLJ2rFDV7/uuPX/s6rokpvFTjBryepeFigH+zKdw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=sourceware.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none Received: from MW3PR06CA0021.namprd06.prod.outlook.com (2603:10b6:303:2a::26) by MN0PR12MB5882.namprd12.prod.outlook.com (2603:10b6:208:37a::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.14; Mon, 20 Jun 2022 17:19:37 +0000 Received: from CO1NAM11FT067.eop-nam11.prod.protection.outlook.com (2603:10b6:303:2a:cafe::bc) by MW3PR06CA0021.outlook.office365.com (2603:10b6:303:2a::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.20 via Frontend Transport; Mon, 20 Jun 2022 17:19:36 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by CO1NAM11FT067.mail.protection.outlook.com (10.13.174.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5353.14 via Frontend Transport; Mon, 20 Jun 2022 17:19:36 +0000 Received: from khazad-dum.amd.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.28; Mon, 20 Jun 2022 12:19:34 -0500 From: Lancelot SIX To: CC: , Lancelot SIX Subject: [PATCH v2 0/3] Fix some use-after-free errors in varobj code Date: Mon, 20 Jun 2022 18:19:12 +0100 Message-ID: <20220620171915.509358-1-lancelot.six@amd.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c2418f8f-46d7-4204-c37f-08da52e10ce4 X-MS-TrafficTypeDiagnostic: MN0PR12MB5882:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: EOHgGjpnO8bum3GzrnbyAASM5Co/lZMfOo3TIvg3ZyAzGw3K1vTRYQnc9dpvv+pPbJ5cTSChWJN5GS2Wc/mHc+MXdTlMiQV/Dt+yL/S0d4fiKdXBgxd8ScQ/QCKDpwpodfTNzTmzPzvb+luToSFNEqQSkOtxHABWLqQ7sXG5OgASqf+I9buY2/EPunIBv2Ap+Uj+rikjDrmSrOCQBKuy5in1nKwUhnFdgLAC265Z6nfLVsDMjN297xfFIA2xilkEkG6Srs3NXe/h/y1krtcL/esJsOG6H3IJdwq0ZMzdSAV7VEy65G3BidLP++QGolVdJk6BmT8UzD/kcwdsU/Zv8m8UIjS9EIC/dS+Y0RB1KstnjGzrm/vaU8ibArcFiqcHXkxLhOWuhZvvdPI5dbt28P/7jq1ipGVPXuQUGXKZsoPs4yPCjcf3/rf+/BwRVkmfzWy32kjJaCki/V1PYUIVeKGIIjjWL+dM52APYVbeeSidEMCROA5RGCSL83GTILX7qDeXH+CKnbo6eIWM59EitpPt6/c9c/TS8j+BA7khk3UBShTqlhAyrthFByoVmYWs1YqPml61nGxYuk5iRU6JnqIIMe2aWXlrkxY/9O/VeNc1lM6Dddn2pgzDpnKjoxGYeuvjkJjzpZwSmQgU/roW3Njo+CRdNBwrpNeJkr+kG/xvBxJXgYolJfusmMSPVk5QBvXL2Z/iYuWxI+lQbDeE8GyhqVAEZJqhD093qsWJANPQH2ggqTuJbq6CUknoQOauZPmjC6DRmyJ58ww/vkFc85hU0QaOFl9fEEU283ziBHIog/t0CXDoZAkQseyLkbpZJTg2+1IbDtU6aM9VdwefEQ== X-Forefront-Antispam-Report: CIP:165.204.84.17; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:SATLEXMB04.amd.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230016)(4636009)(39860400002)(396003)(376002)(136003)(346002)(40470700004)(36840700001)(46966006)(6916009)(2906002)(966005)(356005)(316002)(16526019)(36860700001)(83380400001)(86362001)(54906003)(478600001)(70206006)(40460700003)(8936002)(5660300002)(2616005)(426003)(186003)(1076003)(6666004)(336012)(41300700001)(26005)(82310400005)(8676002)(40480700001)(7696005)(36756003)(82740400003)(81166007)(70586007)(4326008)(47076005)(36900700001); DIR:OUT; SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2022 17:19:36.1909 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c2418f8f-46d7-4204-c37f-08da52e10ce4 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d; Ip=[165.204.84.17]; Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CO1NAM11FT067.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5882 X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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: Mon, 20 Jun 2022 17:19:41 -0000 Hi, this is a V2 for https://sourceware.org/pipermail/gdb-patches/2022-June/190138.html. Noticeable changes since V1: Patch #1: - Added a hunk which somehow slipped into patch #2 in the previous iteration. Patch #2: - Address Andrew's comments. - Removed the change in gdb/testsuite/lib/mi-support.exp as this change really belonged to Patch #1. - Reworked the testcase - Only rely on dlclose to trigger the new code. Do not reload the binary and restart the process as this involves varobj_invalidate. This part of the test is moved to patch #3. - Remove the var->root->exp == nullptr from value_of_root as this case cannot happen as discussed in https://sourceware.org/pipermail/gdb-patches/2022-June/190171.html Patch #3: - Reworked the testcase to highlight that a varobj tracking a global from the main executable is re-created when reloading the process while a varobj tracking a global in a lazily loaded shlib stays invalidated. --- Hi, This series aims at fixing some use-after free errors we have observed around the varobj code. When a objfile is freed, the varobj can keep references to the objfile and to objects that used to live on the objfile's objstack (types among other things). This can mainly be observed when debugging code which loads and unloads shared libraries during its lifetime. Without such scenario the problems exist but are rarely exposed as the references to freed memory are not used. The first patch of the series was originally written by Pedro. It improves mi-support.exp so `mi_runto` now accepts a `-pending` flag, which will be used in the following patch. Patch #2 fixes the actual use-after free errors by ensuring that we clear all references to the objfile before it is freed. Patch #3 fix some inaccuracies in the current varobj_invalidate mechanism which is used to invalidate/recreate varobj when loading a new objfile. All feedback are welcome. Regression tested on x86_64. Lancelot SIX (2): gdb/varobj: Fix use after free in varobj gdb/varobj: Fix varobj_invalidate_iter Pedro Alves (1): MI: mi_runto -pending .../gdb.mi/mi-var-invalidate-shlib-lib.c | 30 +++++ .../gdb.mi/mi-var-invalidate-shlib.c | 43 ++++++ .../gdb.mi/mi-var-invalidate-shlib.exp | 124 ++++++++++++++++++ gdb/testsuite/lib/mi-support.exp | 68 +++++++++- gdb/value.c | 27 ++++ gdb/varobj.c | 80 +++++++++-- 6 files changed, 357 insertions(+), 15 deletions(-) create mode 100644 gdb/testsuite/gdb.mi/mi-var-invalidate-shlib-lib.c create mode 100644 gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.c create mode 100644 gdb/testsuite/gdb.mi/mi-var-invalidate-shlib.exp base-commit: 5fb28d2607a8325559b44a5dc0c8760236c81218 -- 2.25.1