From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1264 invoked by alias); 18 May 2012 18:01:05 -0000 Received: (qmail 1255 invoked by uid 22791); 18 May 2012 18:01:04 -0000 X-SWARE-Spam-Status: No, hits=-7.4 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; Fri, 18 May 2012 18:00:41 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q4II0eXg028294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 18 May 2012 14:00:40 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q4II0doT005582; Fri, 18 May 2012 14:00:39 -0400 Message-ID: <4FB68E47.1080903@redhat.com> Date: Fri, 18 May 2012 18:01: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> <87obplgz9q.fsf@fleche.redhat.com> In-Reply-To: <87obplgz9q.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-05/txt/msg00704.txt.bz2 On 05/18/2012 06:44 PM, Tom Tromey wrote: >>>>>> "Jan" == Jan Kratochvil writes: > > Jan> With proper C++ sanity check of stale live frame_info references > Jan> the testcase would be simple without the "frame_garbage_collection" > Jan> reproducer below. It is also reproducible just with valgrind but > Jan> regularly running the whole testsuite under valgrind I did not find > Jan> feasible. > > I was thinking about this problem recently. > > One idea would be to only let unwinders access struct frame_info, and > have all other code use struct frame_id, perhaps with some simple cache > so that repeated calls for a given frame_id will not cause too much > work. > > This would make it much harder to cache information when not allowed. > > On the minus side, there are 1300 uses of struct frame_info to audit. We invalidate the frame chain when something, anything, changes memory or registers in the inferior, or we do something else that might change our view of the frame stack (such as loading symbols). But, setting a breakpoint doesn't really change the inferior's memory from most of GDB code's perspective, including the frame machinery, because reading back the memory we just written to always gives back the contents as if the breakpoint wasn't planted in the first place (due to shadowing). So it's garanteed (minus bugs), that the rebuilt cache will be a clone of the original cache. We also only have one global cache, not a cache per thread (which I don't think would be a good idea, considering inferiors with many many threads), as and such we flush the cache whenever we change threads, even if for some internal operation, like installing a breakpoint. But, if we build a cache for thread A, flip to thread B for a second, and then flip back to thread A, while having done nothing that might have changed our view of the frame chain, the frame chain built for thread A the second time should be the exact same as what was build before flipping to thread B. It seems to me that combining the both points, we should be able to get back the old behavior, where calling a breakpoint insertion function wouldn't invalidate the frame chain. -- Pedro Alves