From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 2770E3858D1E for ; Tue, 5 Apr 2022 16:40:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2770E3858D1E Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-627-DrB2QxMWN1acS110U5xu8w-1; Tue, 05 Apr 2022 12:39:59 -0400 X-MC-Unique: DrB2QxMWN1acS110U5xu8w-1 Received: by mail-ed1-f71.google.com with SMTP id l2-20020a056402028200b0041cd2975b87so3752716edv.22 for ; Tue, 05 Apr 2022 09:39:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ypJHZtncVAne9ChGeV7VxWJRmsK3QdXBAwq0YCh1ywI=; b=x+gN6o2nMiClIPcof4DagdAUdSCnAkt7H3H+NWTp+3h8YRx1d4zDDV0DD53hRnDU77 oWlUwPU7IpFQ48CIg3r+yP/WzkD4G9fOchz2y3eI91snts7NJS3XMjfiHtlWMEDnWNbB xAyErBTnfWVG1TnfpJ1ZBYhgkdaYiE8hzNk3fZHFQbRORv08zZtISZ6EJ8xF9WJNF447 +xHsBgMqgRT0BXswFiyZQ2iQuJgn3lKgP4XW49WlRXRwJGZ5sPHnYkc50/MFhMzehaoQ v3IxDajba2jbmauWF+QA3KEWfl1r6172U+qRMnJmsekP9j35GQzRFLzhLGjBfBwMvl2U h1aQ== X-Gm-Message-State: AOAM532pTHIhs+ud7HkeNbztwgdQ0fx3BzXtH2PfE9H3onsbj3PMlv7f RJWxqxIDO3Mr7p45kynJziVLa+ZqZgGv/XbC4DD8lL52dGaF7EIb+DpIsH+EcBuE0Ou5y+iPtor QbFDaXiYgIVpIJAPcck34gw== X-Received: by 2002:a50:e79b:0:b0:41c:dd2c:3e19 with SMTP id b27-20020a50e79b000000b0041cdd2c3e19mr4520980edn.291.1649176798334; Tue, 05 Apr 2022 09:39:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxi7OHVIhMKDRBvKiIjn8M2SMyhlxD35Rkf4ThrbKRd7oUBgljzcT297TcrXxj8wuAGbp0Nvg== X-Received: by 2002:a50:e79b:0:b0:41c:dd2c:3e19 with SMTP id b27-20020a50e79b000000b0041cdd2c3e19mr4520969edn.291.1649176798108; Tue, 05 Apr 2022 09:39:58 -0700 (PDT) Received: from localhost (92.40.179.193.threembb.co.uk. [92.40.179.193]) by smtp.gmail.com with ESMTPSA id o3-20020aa7dd43000000b00419db53ae65sm6826709edw.7.2022.04.05.09.39.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Apr 2022 09:39:57 -0700 (PDT) Date: Tue, 5 Apr 2022 17:39:55 +0100 From: Andrew Burgess To: Bruno Larsen Cc: Tom Tromey , Bruno Larsen via Gdb-patches Subject: Re: [PATCH] gdb/stack.c: avoid stale pointers when printing frame arguments Message-ID: <20220405163955.GX1212730@redhat.com> References: <20220328175729.52215-1-blarsen@redhat.com> <87y20khdmy.fsf@tromey.com> <038cc489-18f0-47ee-443c-cb0c651d0fd5@redhat.com> <8735irhbsz.fsf@tromey.com> MIME-Version: 1.0 In-Reply-To: X-Operating-System: Linux/5.8.18-100.fc31.x86_64 (x86_64) X-Uptime: 17:38:19 up 37 days, 6:16, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Tue, 05 Apr 2022 16:40:02 -0000 * Bruno Larsen via Gdb-patches [2022-04-05 11:47:20 -0300]: > On 4/5/22 10:58, Tom Tromey wrote: > > > > > > > "Bruno" == Bruno Larsen writes: > > > > Bruno> This sounds like a good idea. I am just not sure if you are > > Bruno> suggesting it as a fix instead of what I proposed, or to > > Bruno> implement later, can you clarify it please? > > > > You don't have to do it. > > > > Bruno> + if (frame_cache_count < get_frame_cache_generation ()) > > Bruno> + reinit_frame_cache (); > > > > > > I don't think I understand this bit. If the generation changes, > > > > hasn't > > > > the cache already been cleared? > > > > Bruno> If the cache has been cleared by printing a frame, it was done because > > Bruno> a function was called manually (probably). If it did happen, the cache > > Bruno> may have been invalidated and it is safer to rebuild > > Bruno> everything. print_frame_cache by itself doesn't reinitialize the frame > > Bruno> cache. > > > > My understanding is that the generation only changes when > > reinit_frame_cache is called. So if that's the case, why does it need > > to be reinitalized a second time? That's the part I don't understand. > > It has been reinitialized to call the function by hand (if you set > debug frame 1 and call something by hand, you'll see a few > refreshes), but it is not been refreshed after finishing the > handmade call. We might still have dummy frames or incorrect > information leftover from the function call. If the handmade (inferior) call can leave invalid frames in the frame cache, then the correct thing (I would think) is to flush the frame cache after making the inferior call. Thanks, Andrew