From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31286 invoked by alias); 21 Nov 2004 00:42:27 -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 31277 invoked from network); 21 Nov 2004 00:42:23 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 21 Nov 2004 00:42:23 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CVfo0-0006zn-7V; Sat, 20 Nov 2004 19:42:16 -0500 Date: Sun, 21 Nov 2004 00:42:00 -0000 From: Daniel Jacobowitz To: David Lecomber Cc: Eli Zaretskii , patches Subject: Re: [PATCH] Seg fault whilst stepping when watch set [ping!] [in breakpoint.c] Message-ID: <20041121004216.GB26335@nevyn.them.org> Mail-Followup-To: David Lecomber , Eli Zaretskii , patches References: <01c4cef8$Blat.v2.2.2$3fd12960@zahav.net.il> <1100996751.22991.39.camel@cpc2-oxfd5-5-0-cust91.oxfd.cable.ntl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1100996751.22991.39.camel@cpc2-oxfd5-5-0-cust91.oxfd.cable.ntl.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-11/txt/msg00418.txt.bz2 On Sun, Nov 21, 2004 at 12:25:51AM +0000, David Lecomber wrote: > > Also, last time we talked, I asked whether this could be due to the > > Fedora exec-shield feature, but didn't see any response to that. > > Could you please check that? > > I'm not sure how to verify that one - the seg fault happens running as > either root or normal user, if that's related.. You can disable it in /proc somewhere. > Thanks for looking at this bug, here's the latest stack trace and > session log for current CVS: > > Program received signal SIGSEGV, Segmentation fault. > evaluate_subexp (expect_type=0x0, exp=0x0, pos=0xbfffed14, > noside=EVAL_NORMAL) at eval.c:71 > 71 return (*exp->language_defn->la_exp_desc->evaluate_exp) > (gdb) bt > #0 evaluate_subexp (expect_type=0x0, exp=0x0, pos=0xbfffed14, > noside=EVAL_NORMAL) at eval.c:71 > #1 0x080f120d in evaluate_expression (exp=0x0) at eval.c:161 > #2 0x080e159d in insert_bp_location (bpt=0x85208d0, > tmp_error_stream=0x8493008, disabled_breaks=0xbfffedb0, > process_warning=0xbfffedb4, hw_breakpoint_error=0xbfffedb8) at > breakpoint.c:949 Presumably we went wrong at breakpoint.c:7299. > (gdb) watch i > During symbol reading, incomplete CFI data; unspecified registers (e.g., > eax) at 0x804bc35. > Hardware watchpoint 2: i > (gdb) n > Error in re-setting breakpoint 2: > No symbol "i" in current context. > During symbol reading, incomplete CFI data; unspecified registers (e.g., > eax) at 0xb7f3b612. > # 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; if we can't re-parse it, then probably we should disable it. We could mark it disabled before attempting to re-enable it, or catch the error. 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! -- Daniel Jacobowitz