From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4250 invoked by alias); 21 Nov 2004 06:48:21 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 4202 invoked from network); 21 Nov 2004 06:48:15 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 21 Nov 2004 06:48:15 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CVlW9-0000Ey-0Z; Sun, 21 Nov 2004 01:48:13 -0500 Date: Sun, 21 Nov 2004 06:48:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: david@streamline-computing.com, gdb-patches@sources.redhat.com Subject: Re: [PATCH] Seg fault whilst stepping when watch set [ping!] [in breakpoint.c] Message-ID: <20041121064812.GA909@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , david@streamline-computing.com, gdb-patches@sources.redhat.com References: <01c4cef8$Blat.v2.2.2$3fd12960@zahav.net.il> <1100996751.22991.39.camel@cpc2-oxfd5-5-0-cust91.oxfd.cable.ntl.com> <20041121004216.GB26335@nevyn.them.org> <01c4cf8a$Blat.v2.2.2$c01d5200@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c4cf8a$Blat.v2.2.2$c01d5200@zahav.net.il> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-11/txt/msg00426.txt.bz2 On Sun, Nov 21, 2004 at 07:26:08AM +0200, Eli Zaretskii wrote: > > Date: Sat, 20 Nov 2004 19:42:16 -0500 > > From: Daniel Jacobowitz > > Cc: Eli Zaretskii , patches > > > > Presumably we went wrong at breakpoint.c:7299. > > I'm not sure I follow: that place frees the expression and its value, > but then proceeds to parse and evaluate it again. Are you saying that > we threw an error there, and thus left the expression unparsed and/or > unevaluated? > > David, can you please see if something went wrong near line 7299 in > breakpoint.c? > > > If we can't reset the breakpoint, it should be disabled, and we > > shouldn't be re-inserting it. If parse_exception throws an error, then > > the breakpoint is left enabled but without a valid expression. That > > should be fixed instead > > I agree. > > However, if parse_expression (I take it that parse_exception is a > typo) threw an error near breakpoint.c:7299, then wouldn't it throw > the same exception when invoked again in the patch suggested by David? Oops. Yes, it's a typo. Presumably, the difference is the context. In one we're in the context of whatever triggered the reload; in the other (by luck?) we're in the original context, where the local variable "i" is back in scope. This is all very fishy; it works right for globals, but the case of handling a watchpoint on a local variable when resetting breakpoints was never planned for. > > It still won't work right; whatever is causing breakpoints to be reset > > will disrupt any local breakpoints, because of the comment at line > > 7283. We could do better in the case where the objfile that used to > > contain the breakpoint has not been changed. I don't know what caused > > breakpoints to be reset, but it was probably not reloading symbols for > > the executable! > > David, can you see what caused the watchpoint to be re-set? I'm quite curious about this. Maybe the Intel compiler is loading a shared library behind the user's back? -- Daniel Jacobowitz