From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3078 invoked by alias); 21 Nov 2004 05:29:31 -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 3071 invoked from network); 21 Nov 2004 05:29:27 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org with SMTP; 21 Nov 2004 05:29:27 -0000 Received: from zaretski ([80.230.143.196]) by legolas.inter.net.il (MOS 3.5.5-GR) with ESMTP id DDU55245 (AUTH halo1); Sun, 21 Nov 2004 07:28:48 +0200 (IST) Date: Sun, 21 Nov 2004 05:29:00 -0000 From: "Eli Zaretskii" To: Daniel Jacobowitz Message-ID: <01c4cf8a$Blat.v2.2.2$c01d5200@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: david@streamline-computing.com, gdb-patches@sources.redhat.com In-reply-to: <20041121004216.GB26335@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 20 Nov 2004 19:42:16 -0500) Subject: Re: [PATCH] Seg fault whilst stepping when watch set [ping!] [in breakpoint.c] Reply-to: Eli Zaretskii 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> X-SW-Source: 2004-11/txt/msg00425.txt.bz2 > 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? > 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?