From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from progateway7-pub.mail.pro1.eigbox.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by sourceware.org (Postfix) with ESMTPS id 1818F3858D32 for ; Wed, 15 Jun 2022 15:43:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1818F3858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com Received: from cmgw13.mail.unifiedlayer.com (unknown [10.0.90.128]) by progateway7.mail.pro1.eigbox.com (Postfix) with ESMTP id 48BF110047AEF for ; Wed, 15 Jun 2022 15:43:24 +0000 (UTC) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTP id 1VAxoiytBxkuL1VAxoPua7; Wed, 15 Jun 2022 15:43:24 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=GuaHRm5C c=1 sm=1 tr=0 ts=62a9fe1c a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=JPEYwPQDsx4A:10:nop_rcvd_month_year a=Qbun_eYptAEA:10:endurance_base64_authed_username_1 a=CCpqsmhAAAAA:8 a=V9hr56u0BxTUFID3dKUA:9 a=ul9cdbp4aOFLsgKbc677:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=AtUAuZOYE5wCJiEmJG8AiFGswUcxYtfpEh8eHsTdfpY=; b=VJzg34Jj05qqaY+mraUvUYqcWZ r47E+Gg+aU6/PRvorBTUUPRl/k/8il2mILR/HqjlYTXYN7CM2dzOLkJHC6rmTu33jY9g8J//tpr/E qqjOpyBkqTbF6Wuy8pmVwIRSH; Received: from 71-211-187-180.hlrn.qwest.net ([71.211.187.180]:55904 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1o1VAx-002uYP-Cm; Wed, 15 Jun 2022 09:43:23 -0600 From: Tom Tromey To: Bruno Larsen via Gdb-patches Subject: Re: [PATCH v2] gdb/stack.c: avoid stale pointers when printing frame arguments References: <20220504191036.143360-1-blarsen@redhat.com> X-Attribution: Tom Date: Wed, 15 Jun 2022 09:43:22 -0600 In-Reply-To: <20220504191036.143360-1-blarsen@redhat.com> (Bruno Larsen via Gdb-patches's message of "Wed, 4 May 2022 16:10:36 -0300") Message-ID: <87letyx78l.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 71.211.187.180 X-Source-L: No X-Exim-ID: 1o1VAx-002uYP-Cm X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 71-211-187-180.hlrn.qwest.net (murgatroyd) [71.211.187.180]:55904 X-Source-Auth: tom+tromey.com X-Email-Count: 1 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-Spam-Status: No, score=-3018.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, JMQ_SPF_NEUTRAL, RCVD_IN_BL_SPAMCOP_NET, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Wed, 15 Jun 2022 15:43:26 -0000 >>>>> "Bruno" == Bruno Larsen via Gdb-patches writes: Bruno> @@ -738,8 +738,17 @@ call_function_by_hand (struct value *function, Bruno> type *default_return_type, Bruno> gdb::array_view args) Bruno> { Bruno> - return call_function_by_hand_dummy (function, default_return_type, Bruno> - args, NULL, NULL); Bruno> + scoped_restore_selected_frame restore_frame; Bruno> + struct value *ret = call_function_by_hand_dummy (function, Bruno> + default_return_type, Bruno> + args, NULL, NULL); Bruno> + /* Ensure that the frame cache does not contain any frames that were Bruno> + specific to the handmade function call. If something is leftover Bruno> + while GDB has kept a reference to a frame (for instance, when a Bruno> + stacktrace is being printed and a pretty printed called an inferior Bruno> + function), GDB could crash. */ Bruno> + reinit_frame_cache (); I don't understand the need for this call. It seems like it must be redundant, because the frame cache should be reset by causing the inferior to run during the inferior call. Bruno> + struct frame_id id = get_frame_id (get_selected_frame (NULL)); Bruno> if (execution_direction == EXEC_REVERSE) Bruno> gdb_printf (_("Run back to call of ")); Bruno> else Bruno> @@ -1866,6 +1867,10 @@ finish_command (const char *arg, int from_tty) Bruno> } Bruno> print_stack_frame (get_selected_frame (NULL), 1, LOCATION, 0); Bruno> + frame = frame_find_by_id (id); Bruno> + if (frame == nullptr) Bruno> + error (_("frames disappeared mid-printing.")); Bruno> + frame = get_prev_frame (frame); This code probably needs a comment since it's non-obvious why 'finish' would need to do the frame-id thing. I think error text normally does not end in ".". I see a lot of these though, I wonder if we ought to remove them all. Bruno> + error (_("frames disappeared mid-printing.")); Here too. Bruno> + /* print_frame can invalidate frame, so cache the frame_id to rebuild Bruno> + the whole stack later, if needed. */ Bruno> + struct frame_id frame_id = get_frame_id (frame); This repeated code makes me wonder if perhaps the print_frame_info API ought to be changed instead. Tom