From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21713 invoked by alias); 4 Feb 2008 22:36:54 -0000 Received: (qmail 21689 invoked by uid 22791); 4 Feb 2008 22:36:53 -0000 X-Spam-Check-By: sourceware.org Received: from blaster.systems.pipex.net (HELO blaster.systems.pipex.net) (62.241.163.7) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 04 Feb 2008 22:36:28 +0000 Received: from [192.168.123.6] (88-106-248-241.dynamic.dsl.as9105.com [88.106.248.241]) by blaster.systems.pipex.net (Postfix) with ESMTP id 20198E000A94; Mon, 4 Feb 2008 22:36:25 +0000 (GMT) Message-ID: <47A79369.8030709@undo-software.com> Date: Mon, 04 Feb 2008 22:36:00 -0000 From: Greg Law User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: 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> In-Reply-To: <20080204221036.GA26939@caradoc.them.org> Content-Type: multipart/mixed; boundary="------------090305000604060407010402" 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/msg00095.txt.bz2 This is a multi-part message in MIME format. --------------090305000604060407010402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 924 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/ --------------090305000604060407010402 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 --------------090305000604060407010402--