From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6537 invoked by alias); 26 Feb 2008 22:55:07 -0000 Received: (qmail 6519 invoked by uid 22791); 26 Feb 2008 22:55:06 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 26 Feb 2008 22:54:49 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 8117E3BC99; Tue, 26 Feb 2008 14:54:47 -0800 (PST) Subject: Re: SIGSEGV on gdb 6.7* From: Michael Snyder To: Greg Law Cc: gdb-patches@sourceware.org In-Reply-To: <47A77A6C.8050007@undo-software.com> References: <47A77A6C.8050007@undo-software.com> Content-Type: text/plain Date: Tue, 26 Feb 2008 23:00:00 -0000 Message-Id: <1204066487.19253.346.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00415.txt.bz2 On Mon, 2008-02-04 at 20:49 +0000, Greg Law wrote: > Hi list, > > I have been playing with gdb-6.7 and it appears there is a bug whereby > reading registers can cause a SIGSEGV in gdb. The simplest way I've > found to cause the problem is to try to read a register after calling > the flushregs maintenance command: First of all, I apologize for not joining this thread sooner -- it escaped my notice. Secondly, I apologize because I wrote the flushregs maintenance command, and it is clearly wrong. I actually had the impression that I HAD made it flush the frame cache -- I certainly meant to. That said -- I agree with Daniel. I can see where flushing the register cache and flushing the frame cache are two things that should probably always be done at the same time -- but I'm worried about the extra overhead that this patch introduces. We call registers_changed A LOT, and in doing so we assume that it has a very low overhead. I would prefer to just fix the reg_flush_command function for now, and return to the question "should registers_changed imply reinit_frame_cache (and vice versa) as an architectural question later (or sooner).