From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10122 invoked by alias); 6 Jun 2012 20:16:06 -0000 Received: (qmail 10098 invoked by uid 22791); 6 Jun 2012 20:16:04 -0000 X-SWARE-Spam-Status: No, hits=-7.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 Jun 2012 20:15:47 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q56KFl8O020655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 6 Jun 2012 16:15:47 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q56KFj1q019836; Wed, 6 Jun 2012 16:15:46 -0400 Message-ID: <4FCFBA71.70207@redhat.com> Date: Wed, 06 Jun 2012 20:16:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Tom Tromey CC: Jan Kratochvil , gdb-patches@sourceware.org Subject: Re: [downstream patch FYI] workaround stale frame_info * (PR 13866) References: <20120404191416.GA29603@host2.jankratochvil.net> <4FCE5B14.4030808@redhat.com> <20120605193920.GA19998@host2.jankratochvil.net> <87d35cgrik.fsf@fleche.redhat.com> In-Reply-To: <87d35cgrik.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-06/txt/msg00200.txt.bz2 On 06/06/2012 08:38 PM, Tom Tromey wrote: > Despite the difficulties perhaps we should try to write a static > analyzer for this. I am not sure if it could be made reliable enough, > but maybe it could. The problem cases are when the analyzer must > account for cleanups -- but in this case we might be able to get away > with ignoring them. If that doesn't work, or if it's too much trouble, we could consider putting in a variant of my validation patch. Instead of garbage collecting dead frames at some specific points, keep say, a FIFO of the last N dead frames (don't free them, but mark them dead, catching uses of those). N could be low. That'd keep the extra memory bounded. If this is considered expensive (unlikely), we could guard it behind the new --development flag (kind of like checking in gcc). > Another idea is to simply get rid of frame_info and have only a > frame_id-based API. Most, a large majority of frame_info objects I see (when not a transient use like get_current_frame passed directly to some frame.c function) of what I see is in the unwinders, where that'd unnecessary, and wouldn't really work. Most other places tend to already be careful with frame_info lifetime. There's execution commands (of which "until" was particularly bad), and a handful of other things. There are some paths in handle_inferior_event on software single-step targets that might be hitting stale frame_info (hey, where else would problems be, right?), but in all honesty, I don't think there are that many related lurking bugs to worry that much about. -- Pedro Alves