From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id oQarA+TPJmpROzwAWB0awg (envelope-from ) for ; Mon, 08 Jun 2026 10:21:24 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=JOLhsGXJ; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=APrxLXTu; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=JOLhsGXJ; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=APrxLXTu; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 08BD81E0A3; Mon, 08 Jun 2026 10:21:24 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=unavailable autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 2DBF41E062 for ; Mon, 08 Jun 2026 10:21:23 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B028351A4321 for ; Mon, 8 Jun 2026 14:21:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B028351A4321 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=JOLhsGXJ; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=APrxLXTu; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=JOLhsGXJ; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=APrxLXTu Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by sourceware.org (Postfix) with ESMTPS id 68D3E4C31842 for ; Mon, 8 Jun 2026 14:20:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 68D3E4C31842 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 68D3E4C31842 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=195.135.223.131 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1780928450; cv=none; b=qfCKhovJgCHoPTPVdITfBKazVadsELZQ/I7qrBMq9dxNt/p1OuOLJhZXyLHtzSQvqYUZ7RwO1cL6g3Y6M8UZXHlc2TMSwNLBXXJcqz5LbYWE6LcOtP5rEhSKQj/XUVNbdEmqXzyTlzXjx/WE4h/BjKpiw/d+/Jo6EyiVNeX5UUg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1780928450; c=relaxed/simple; bh=YE3xfW8nuYxNretB4myCM4zB5oPe8qGqRmClS7xmKxg=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature: Message-ID:Date:MIME-Version:Subject:To:From; b=Zh5xTI/vJhnSKbf9tj2dn6xGeyNVnmH5MPdeDh5iOlYsVxfv47o55roCU/KKG9y3d6CKRnfQvuC5dyP84SrZAax8dYvkqVe/5EnrtiGZYqhYqufhN9GvFTwCLTBZHf9yjnKAtml/MMz7RTWqr6qkqN09RriDyCJRGU/whngdpnI= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=JOLhsGXJ; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=APrxLXTu; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=JOLhsGXJ; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=APrxLXTu DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 68D3E4C31842 Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 5F8B667F22; Mon, 8 Jun 2026 14:20:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1780928449; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2UY+ygRYVt7gtYqfnMmtT2EgTeLXz+pIkFFIrSQIIW0=; b=JOLhsGXJXCDMmBb3PFvC7QkrlTwLbHAay09QrxGoPquFHu9WZBWNaZwbbKkXYo3aXIYinX ZtdSuOSDQKSP3Xya7LS+JEhAJUH6Pw6lIJuZupECHnKYw6rlwGYywoGoZboTIk9jjnT1Ap Il42E6SpdEtE8hS9MsF5QgOJPgYzCZ4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1780928449; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2UY+ygRYVt7gtYqfnMmtT2EgTeLXz+pIkFFIrSQIIW0=; b=APrxLXTu3MewDaZA7vKhe56wju+/p0M+wEIeH3PTMMd1WoOqQEH0ZTRTSL97Uh5QURTbv2 vui9plQPpS4ZKxDQ== Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1780928449; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2UY+ygRYVt7gtYqfnMmtT2EgTeLXz+pIkFFIrSQIIW0=; b=JOLhsGXJXCDMmBb3PFvC7QkrlTwLbHAay09QrxGoPquFHu9WZBWNaZwbbKkXYo3aXIYinX ZtdSuOSDQKSP3Xya7LS+JEhAJUH6Pw6lIJuZupECHnKYw6rlwGYywoGoZboTIk9jjnT1Ap Il42E6SpdEtE8hS9MsF5QgOJPgYzCZ4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1780928449; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2UY+ygRYVt7gtYqfnMmtT2EgTeLXz+pIkFFIrSQIIW0=; b=APrxLXTu3MewDaZA7vKhe56wju+/p0M+wEIeH3PTMMd1WoOqQEH0ZTRTSL97Uh5QURTbv2 vui9plQPpS4ZKxDQ== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 4225A779A7; Mon, 8 Jun 2026 14:20:49 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id FKSMDsHPJmqXNAAAD6G6ig (envelope-from ); Mon, 08 Jun 2026 14:20:49 +0000 Message-ID: <7be245c1-7f93-4485-acd6-aaa33b8cb927@suse.de> Date: Mon, 8 Jun 2026 16:20:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] [gdb/symtab] Add assert in free_cached_comp_units constructor To: Simon Marchi , Tom Tromey Cc: gdb-patches@sourceware.org References: <20260527095715.2481440-1-tdevries@suse.de> <87pl2f5vsy.fsf@tromey.com> <83c3a4ea-9f74-4afe-8963-ce0ec9495a22@suse.de> <7168b9e1-3102-4484-928e-53b5e55ffdf4@suse.de> Content-Language: en-US From: Tom de Vries In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-4.29 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.19)[-0.931]; MIME_GOOD(-0.10)[text/plain]; FUZZY_RATELIMITED(0.00)[rspamd.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DBL_BLOCKED_OPENRESOLVER(0.00)[sourceware.org:url, suse.de:email, suse.de:mid, imap1.dmz-prg2.suse.org:helo] X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 6/1/26 5:18 PM, Simon Marchi wrote: > On 6/1/26 4:02 AM, Tom de Vries wrote: >> On 5/30/26 2:52 PM, Tom de Vries wrote: >>> On 5/28/26 6:43 PM, Tom Tromey wrote: >>>>>>>>> "Tom" == Tom de Vries writes: >>>> >>>> Tom> Detect this situation using an assert in the free_cached_comp_units >>>> Tom> constructor. >>>> >>>> Seems fine to me. >>> >>> Thanks for the review. >>> >>> I committed this, but afterwards ran into trouble on x86_64-linux with test-cases gdb.ada/uninitialized-variable-record.exp and gdb.ada/ uninitialized_vars.exp on x86_64-linux, so I've reverted this. >>> >> >> I've investigated this, and found that this is due to calls to load_cu in places other than dw2_do_instantiate_symtab. >> >> For test-case gdb.ada/uninitialized_vars.exp, it's dwarf2_fetch_die_loc_cu_off. >> >> I do wonder if ~free_cached_comp_units is a bit overeager, and should refrain from deleting cached comp units that were present at construction time. >> >> Anyway, the assert detected the use-after-free I created, but just doesn't hold in general. > > Let's try to understand why things are the way they are currently. > > Why do we want to delete the just created dwarf2_cus in > dw2_instantiate_symtab? I presume it's because the chances of them > being useful again are slim. We created the GDB types and symbols, we > don't need to keep the DIE structure loaded in memory, so it's better > to free up the memory. > > The cases where the dwarf2_cus are needed again later appear to be when > evaluating a some DWARF operator that refers to other DIEs directly, > such as DW_OP_call*, DW_OP_implicit_pointer, DW_OP_GNU_variable_value, > etc. > > - dwarf2_fetch_die_loc_sect_off > - dwarf2_fetch_die_loc_cu_off > - dwarf2_fetch_constant_bytes > - dwarf2_fetch_die_type_sect_off > > In those cases we re-load the right dwarf2_cu in memory to be able to > look up the DIE and get what we want from it. In those cases, we don't > free up the just-loaded dwarf2_cu right away, because it presumably has > good chances of being needed again in the near future, for other > operators. We instead use the "age_comp_units" mechanism, which frees > the dwarf2_cus once they have been sitting there unused for a while. > > I am unable to reproduce the gdb.ada failures, but the case that you > looked at appears to be one where a dwarf2_cu was loaded by one of those > "dwarf2_fetch_*" functions, while evaluating a DWARF expression, and > then dw2_instantiate_symtab was called to expand a compunit into full > symbols. So free_cached_comp_units deletes the dwarf2_cu previously > cached by the "dwarf2_fetch_*" functions. I don't think this is wrong > (as in a correctness bug), so I don't think the assert was right, it > might just be ineffcient cache usage. I don't know if it's problematic > enough to be worth fixing, but if you can think of a simple solution for > dw2_instantiate_symtab not to delete the pre-existing dwarf2_cus, we > could consider it. > > It would perhaps be good to investigate whether this "age comp units" > machinery is still working as initially intended. It's possible that > will all the refactors we've done over the years, it's not working as > intended. And because it's just a cache, it would not break any tests, > but it could cause peformance problems. While searching the code, I > looked where `cu->last_used` is reset, to prevent the CU from being > freed by age_comp_units. It is reset in maybe_queue_comp_unit, which is > itself called in: > > - follow_die_sig_1 > - process_imported_unit_die > - follow_die_offset > > Note that those are all used in cross-CU reference cases, when a CU > needs something from another CU. > > `age_comp_units()` is called in: > > - dw2_do_instantiate_symtab, when done expanding the symtab(s) > - dwarf2_fetch_die_loc_sect_off, when done fetching the location info > > Some fishy things I spotted: > > - The age_comp_units() call in dw2_do_instantiate_symtab suggests that > the comp unit aging system was also meant to be used when expanding > symtabs. The fact that all the places that reset `cu->last_used` are > some that handle cross-CU references also suggests this. The idea > might have been that if a CU refers to another CU (via DW_AT_import > for instance), then there is a good chance that subsequent CUs will > also refer to that second CUs. So when you're done expanding the > first CU, better keep that second CU in cache for when you'll be > expanding more CUs. However, if we free up all cached CUs in > dw2_instantiate_symtab via free_cached_comp_units, doesn't it defeat > the purpose? Why call age_comp_units() in dw2_do_instantiate_symtab > if we're going to free them all up in the caller anyway? > > - Calling dwarf2_fetch_die_loc_sect_off ages the comp units, but > shouldn't it also reset the `cu->last_used` field of the CU from > which we found the info? Otherwise, repeated calls to > dwarf2_fetch_die_loc_sect_off targetting the same CU will cause that > CU to be freed, even if we just used it and will keep needing it > (causing it to be re-loaded from scratch the next time). > Hi Simon, thanks for the comments. I'm not sure when I'll have the time to follow up on all this, so I've filed a review PR ( https://sourceware.org/bugzilla/show_bug.cgi?id=34243 ). Thanks, - Tom > Simon