From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10663 invoked by alias); 29 Mar 2005 21:43:12 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 10616 invoked from network); 29 Mar 2005 21:43:09 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 29 Mar 2005 21:43:09 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DGOVS-0002eS-6T; Tue, 29 Mar 2005 16:44:14 -0500 Date: Tue, 29 Mar 2005 21:43:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: GDB Subject: Re: [mi] watchpoint-scope exec async command Message-ID: <20050329214414.GA3498@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , GDB References: <01c53207$Blat.v2.4$3def9b00@zahav.net.il> <20050328225619.GB3413@white> <20050328224101.GA629@nevyn.them.org> <20050328235310.GA3699@white> <20050328230048.GA1697@nevyn.them.org> <20050329014203.GB3801@white> <20050329013634.GB6373@nevyn.them.org> <20050329024945.GC3957@white> <20050329020123.GA7266@nevyn.them.org> <01c534a6$Blat.v2.4$944e44a0@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c534a6$Blat.v2.4$944e44a0@zahav.net.il> User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-03/txt/msg00289.txt.bz2 On Tue, Mar 29, 2005 at 11:29:48PM +0200, Eli Zaretskii wrote: > > how did we fail to delete the watchpoint too? > > > > The answer seems to be that we use disp_del_at_next_stop if we hit the > > _watchpoint_, but not if we hit the related breakpoint. When we delete > > it we ought to be deleting its related breakpoint too (they point to > > each other). But we don't. The only things we ever do with > > related_breakpoints are set their dispositions. > > Sorry, I'm not sure I understand correctly what you are saying, > because of the ambiguous use of "it" and "its". This sentence is the > most ambiguous for me: > > > When we delete it we ought to be deleting its related breakpoint too > > (they point to each other). > > Who is "it" here? If it's the watchpoint, then I don't understand > your reasoning, because if the scope breakpoint rather than the > watchpoint itself triggered, we don't delete anything. "it" was intended to be the scope breakpoint. Sorry, I had to read that three times to work out what I meant, and it was only yesterday. If the scope breakpoint triggers, we delete it. From watch_command_1: /* Automatically delete the breakpoint when it hits. */ scope_breakpoint->disposition = disp_del; That's what's happening in this case. Then, shortly thereafter, the watchpoint triggers. That's when we detect that it has gone out of scope, and set it to delete at next stop; and we crash, because we already deleted the scope breakpoint when it was hit. > > > Please look at the comments at breakpoint.c:6723 and breakpoint.c:1325. > > > > The comment at 6723 doesn't apply to this case, because that's bpstats > > dangling a pointer; the breakpoint chain should never do this. > > ??? My interpretation of that comment is that a breakpoint/watchpoint > that was already deleted should have its type set to bp_none, and in > that case we don't delete it again. What am I missing? Generally, when we delete a breakpoint, we free it; so it doesn't matter what its type gets set to. /* On the chance that someone will soon try again to delete this same bp, we mark it as deleted before freeing its storage. */ bpt->type = bp_none; xfree (bpt->loc); xfree (bpt); All the code surrounding bp_none is horribly bogus; we're walking freed memory if we hit it. I don't know if it still triggers today; probably it does in some cases, and no one's been brave enough to fix them. -- Daniel Jacobowitz CodeSourcery, LLC