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 5ED143858024 for ; Thu, 9 Feb 2023 19:53:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5ED143858024 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.192] (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)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id B6C351E110; Thu, 9 Feb 2023 14:53:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1675972425; bh=4qnbRBHScG2wOy5hVGaH40Tg0MclEn0uItBdVxG0L3g=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=s0ToCTnMbF1fSNVXaNszaQfHbHMcqGjuqXTUylqFI0I1UjmwKTs9DOc2C3dBDLVpr zWfWj/ULs4TLw9R2/5pbtejFfqALJH/xgZ1l2SozTGWTAvIZ8liuHNi/gUVGtbESgM iRwligCOE4ux09uUvVedzvJ4EkgiEHK6TCKNzzQs= Message-ID: <8398b742-6684-a60b-9ee5-fa70dd8991b2@simark.ca> Date: Thu, 9 Feb 2023 14:53:44 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH 1/2] gdb: call frame unwinders' dealloc_cache methods through destroying the frame cache To: Tom de Vries , Simon Marchi , gdb-patches@sourceware.org Cc: "Metzger, Markus T" References: <20230130200249.131155-1-simon.marchi@efficios.com> <20230130200249.131155-2-simon.marchi@efficios.com> <4a9f858c-06f0-0656-29a9-3dab53bad737@suse.de> Content-Language: fr From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 2/9/23 07:42, Tom de Vries via Gdb-patches wrote: > On 2/9/23 08:40, Tom de Vries wrote: >> On 1/30/23 21:02, Simon Marchi via Gdb-patches wrote: >>> Currently, some frame resources are deallocated by iterating on the >>> frame chain (starting from the sentinel), calling dealloc_cache. The >>> problem is that user-created frames are not part of that chain, so we >>> never call dealloc_cache for them. >>> >>> I propose to make it so the dealloc_cache callbacks are called when the >>> frames are removed from the frame_stash hash table, by registering a >>> deletion function to the hash table. This happens when >>> frame_stash_invalidate is called by reinit_frame_cache. This way, all >>> frames registered in the cache will get their unwinder's dealloc_cache >>> callbacks called. >>> >>> Note that at the moment, the sentinel frames are not registered in the >>> cache, so we won't call dealloc_cache for them. However, it's just a >>> theoritical problem, because the sentinel frame unwinder does not >>> provide this callback. Also, a subsequent patch will change things so >>> that sentinel frames are registered to the cache. >>> >>> I moved the obstack_free / obstack_init pair below the >>> frame_stash_invalidate call in reinit_frame_cache, because I assumed >>> that some dealloc_cache would need to access some data on that obstack, >>> so it would be better to free it after clearing the hash table. >>> >> >> For me this causes: >> ... >> (gdb) PASS: gdb.btrace/record_goto.exp: instruction-history from 19 forwards >> record goto 27^M >> /data/vries/gdb/src/gdb/record-btrace.c:1654: internal-error: bfcache_new: Assertion `*slot == NULL' failed.^M >> A problem internal to GDB has been detected,^M >> further debugging may prove unreliable.^M >> ----- Backtrace -----^M >> FAIL: gdb.btrace/record_goto.exp: record goto 27 (GDB internal error) >> ... >> >> Note that I've been having some problems with btrace tests, possible related to cpu/kernel combination (PRs 30073 and 30075), so this may be difficult to reproduce, I'm not sure. >> > > I also managed to reproduce this on openSUSE Tumbleweed, which doesn't show the problems with btrace tests, so I'm hoping this is easy to reproduce. > > Thanks, > - Tom Thanks for reporting. I managed to reproduce on gcc13 (I only have computers with AMD cpus at the moment, so I can't run the btrace tests). I sent a patch, the explications of the cause and proposed solution are there: https://inbox.sourceware.org/gdb-patches/20230209195037.100368-1-simon.marchi@efficios.com/T/#u Simon