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 6B4443858C3A for ; Thu, 14 Mar 2024 13:56:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6B4443858C3A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6B4443858C3A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710424581; cv=none; b=rNuH8N+89c7yLus1MIrhbsVMFqMhT+NvVkZcnIaeMhba7sg4u7iWvR2IODr3EV6brLlbL+2/B5hzeI2Lwkbppjud8KUgqnlFapfDwhBaB8V2+KYJred9Ijv6Pp/EYpRQDPsRXcrNkDCu/Mzvke2Up2Iu3hSvCjrDyLZSVOKsV2Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710424581; c=relaxed/simple; bh=xmpBagseDjOY6ccoOz8O3tnPWRwkKtzBVM1tyrWHPpU=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=MFsZDTqvVgJPt/wCTWH0KAWdZPkPtZvtIP2VICes7NWS7GdMh7+9o0On2qts9dgjPZ82MvGDkIJn97JKzMQwRCfXrXlVAsAgk4NsUrzcY7A5Zlo3ZgH0RnGogiwFPVcw+XEF3HeGSFU6RMv6hII0cMtpLhoKXN4tSRwuiKR69Ic= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1710424578; bh=xmpBagseDjOY6ccoOz8O3tnPWRwkKtzBVM1tyrWHPpU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=wzVJ3jKvwYLb476obs078/xoydpGtUK14PCEJdnyYBI7tULsSUFfh15LjdPP2gkWj f7ReHRrOnqCIa6p+HDUDMzuT0B0k7cCBnuiM1X6RXRUDzbSIYnTQyVvciqM9gdBjGD 6r4/lyl2Yo50aiYcjXePEHkzz1WVDlqIUkiluNxo= Received: from [10.0.0.11] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id C4DCA1E01D; Thu, 14 Mar 2024 09:56:18 -0400 (EDT) Message-ID: <22883d8d-b634-4e71-802c-239114d01279@simark.ca> Date: Thu, 14 Mar 2024 09:56:18 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb/dwarf2: Check for missing abbrev To: Tom Tromey Cc: Aaron Merey , gdb-patches@sourceware.org References: <20240313201827.1853989-1-amerey@redhat.com> <878r2lm1un.fsf@tromey.com> Content-Language: en-US From: Simon Marchi In-Reply-To: <878r2lm1un.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 List-Id: On 2024-03-14 08:31, Tom Tromey wrote: >>>>>> "Simon" == Simon Marchi writes: > > Simon> However, I'd like if we could analyze the problem a bit further to > Simon> understand more precisely what happens, just to be sure that there isn't > Simon> a more fundamental problem and we're not just papering over the problem. > > The issue is corrupt DWARF -- the DIE specifies an abbrev that doesn't exist. If it was an abbrev number that didn't exist, then peek_die_abbrev would throw here: const abbrev_info *abbrev = reader.abbrev_table->lookup_abbrev (abbrev_number); if (!abbrev) { error (_("Dwarf Error: Could not find abbrev number %d in %s" " at offset %s [in module %s]"), abbrev_number, cu->per_cu->is_debug_types ? "TU" : "CU", sect_offset_str (cu->header.sect_off), bfd_get_filename (abfd)); } If peek_die_abbrev returns nullptr, it's because it read abbrev number 0 specifically (which normally means "end of DIE list", but is unexpected at this particular place). So I'm just wondering what "kind" of corruption causes it to be 0. The concrete case I'm worried about is the possibility that the file is truncated and we go read an offset that is out of our buffer's bounds. In that case, some bounds checking should probably be added somehwere. If the file is not truncated and just contains a bunch of 0s where it shouldn't because debuginfod crashed while writing it, then just erroring out in scan_attributes (after the peek_die_abbrev call) is fine. > Whether erroring here is the best result is harder to say. For example, > would it make more sense to terminate the scanning but still install any > symbols seen before this point? > > I tend to agree that this approach is ok, though. If the file is > corrupt it seems fine to lose a few symbols, or maybe even the whole > thing. I think that erroring out is fine, certainly better than crashing. Simon