From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 7CD50385B524 for ; Tue, 13 Dec 2022 21:32:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7CD50385B524 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [172.16.0.64] (192-222-180-24.qc.cable.ebox.net [192.222.180.24]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 2BF411E112; Tue, 13 Dec 2022 16:32:30 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1670967150; bh=48kBeD+shqKk2nxb68h4AWU7dhf2HVwOmV4PYIjP7wg=; h=Date:Subject:To:References:From:In-Reply-To:From; b=GMVJdnhsFkaH+1BwxBB41ZYF6BICkBprPKAn9dWSu0nfggK0dzr8w/TepuBZ92r9+ nGkwlVO2BOiYTEqUb/rVnNCMUkCgWDmZrWqy2jl524Yu/nwOvAi7DjXsyhnfuTlv6d lLC/KDrtSFSjTg5RInv9cQo1khhgEAbsr3wQmWjM= Message-ID: Date: Tue, 13 Dec 2022 16:32:29 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [PATCH] Avoid double-free with debuginfod Content-Language: fr To: Tom Tromey , gdb-patches@sourceware.org References: <20221212183852.1502020-1-tromey@adacore.com> From: Simon Marchi In-Reply-To: <20221212183852.1502020-1-tromey@adacore.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-11.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,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 List-Id: On 12/12/22 13:38, Tom Tromey via Gdb-patches wrote: > PR gdb/29257 points out a possible double free when debuginfod is in > use. Aside from some ugly warts in the symbol code (an ongoing > issue), the underlying issue in this particular case is that elfread.c > seems to assume that symfile_bfd_open will return NULL on error, > whereas in reality it throws an exception. As this code isn't > prepared for an exception, bad things result. > > This patch fixes the problem by introducing a non-throwing variant of > symfile_bfd_open and using it in the affected places. > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29257 I don't know how the debuginfo tests in our testsuite work... would it be easy to make a test that mimics the reproduction steps given in the bug? You would build an executable without debug info, then make an empty file with the approrpriate name in the debuginfod cache. > diff --git a/gdb/symfile.h b/gdb/symfile.h > index ffd1acddfdb..61d69c4e412 100644 > --- a/gdb/symfile.h > +++ b/gdb/symfile.h > @@ -269,6 +269,11 @@ extern void set_initial_language (void); > > extern gdb_bfd_ref_ptr symfile_bfd_open (const char *); > > +/* Like symfile_bfd_open, but will not throw an exception on error. > + Instead, it issues a warning and returns nullptr. */ > + > +extern gdb_bfd_ref_ptr symfile_bfd_open_no_error (const char *); Maybe mark the function noexcept? Simon