From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17422 invoked by alias); 11 Feb 2008 20:59:38 -0000 Received: (qmail 17411 invoked by uid 22791); 11 Feb 2008 20:59:37 -0000 X-Spam-Check-By: sourceware.org Received: from mk-outboundfilter-1.mail.uk.tiscali.com (HELO mk-outboundfilter-1.mail.uk.tiscali.com) (212.74.114.37) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 11 Feb 2008 20:59:05 +0000 X-Trace: 38716817/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.162.32 X-SBRS: None X-RemoteIP: 62.241.162.32 X-IP-MAIL-FROM: glaw@undo-software.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGpFsEc+8aIg/2dsb2JhbACqHQ X-IP-Direction: IN Received: from ranger.systems.pipex.net ([62.241.162.32]) by smtp.pipex.tiscali.co.uk with ESMTP; 11 Feb 2008 20:59:02 +0000 Received: from [192.168.123.6] (82-71-15-62.dsl.in-addr.zen.co.uk [82.71.15.62]) by ranger.systems.pipex.net (Postfix) with ESMTP id 5F2F6E00008A; Mon, 11 Feb 2008 20:59:00 +0000 (GMT) Message-ID: <47B0B714.1020707@undo-software.com> Date: Mon, 11 Feb 2008 20:59:00 -0000 From: Greg Law User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sourceware.org Subject: Re: SIGSEGV on gdb 6.7* References: <47A77A6C.8050007@undo-software.com> <20080204210333.GA23250@caradoc.them.org> <47A7850B.10202@undo-software.com> <20080204214504.GA25564@caradoc.them.org> <47A78A92.8000501@undo-software.com> <20080204221036.GA26939@caradoc.them.org> <47A79369.8030709@undo-software.com> In-Reply-To: <47A79369.8030709@undo-software.com> Content-Type: multipart/mixed; boundary="------------030907070400040101040304" 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: 2008-02/txt/msg00184.txt.bz2 This is a multi-part message in MIME format. --------------030907070400040101040304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1111 Hi Daniel, Any chance this patch (or its equivalent) could get applied? (Attached again for the sake of convenience.) Cheers, Greg Greg Law wrote: > Daniel Jacobowitz wrote: >> On Mon, Feb 04, 2008 at 09:58:42PM +0000, Greg Law wrote: >>> Should it be just flushregs that invalidates the frame cache, or >>> should it happen from registers_changed()? >> >> Good question :-) Probably registers_changed, but I suspect that >> makes a lot of other reinit_frame_cache calls redundant. >> > > Well, calling reinit_frame_cache() from registers_changed() does indeed > fix the problem. It doesn't seem that a few redundant calls to > reinit_frame_cache() is a big issue: if it's already NULL then there > isn't much work for that function to do. OTOH, not calling it where it > should be called clearly is pretty serious. > > The attached patch does this. I guess copyright assignment etc is > rather over the top for such a small change, but if you prefer we go > through those hoops then I'm happy to do so. > > g > -- Greg Law, Undo Software http://undo-software.com/ --------------030907070400040101040304 Content-Type: text/x-patch; name="regcache_fix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="regcache_fix.patch" Content-length: 658 Index: gdb/regcache.c =================================================================== RCS file: /cvs/src/src/gdb/regcache.c,v retrieving revision 1.163 diff -u -r1.163 regcache.c --- gdb/regcache.c 1 Jan 2008 22:53:12 -0000 1.163 +++ gdb/regcache.c 4 Feb 2008 22:24:32 -0000 @@ -472,6 +472,9 @@ regcache_xfree (current_regcache); current_regcache = NULL; + /* Need to forget about any frames we have cached, too. */ + reinit_frame_cache (); + /* Force cleanup of any alloca areas if using C alloca instead of a builtin alloca. This particular call is used to clean up areas allocated by low level target code which may build up --------------030907070400040101040304--