From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31783 invoked by alias); 29 Mar 2005 02:00:32 -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 31744 invoked from network); 29 Mar 2005 02:00:24 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 29 Mar 2005 02:00:24 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DG62l-0001x1-L6; Mon, 28 Mar 2005 21:01:23 -0500 Date: Tue, 29 Mar 2005 02:00:00 -0000 From: Daniel Jacobowitz To: GDB Cc: Eli Zaretskii Subject: Re: [mi] watchpoint-scope exec async command Message-ID: <20050329020123.GA7266@nevyn.them.org> Mail-Followup-To: GDB , Eli Zaretskii References: <20050325161239.GA12231@white> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050329024945.GC3957@white> User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-03/txt/msg00275.txt.bz2 On Mon, Mar 28, 2005 at 09:49:45PM -0500, Bob Rossi wrote: > > > breakpoint.c:5761 is where the related_breakpoint is allocated > > > breakpoint.c:6721 is where the related_breakpoint is deleted > > > breakpoint.c:1022 is where the problem occurs (just the next sucker to > > > read/write the free'd related_breakpoint field) > > > > > > So, at breakpoint.c:5761 I do, > > > (tgdb) p b > > > $1 = (struct breakpoint *) 0x83b4878 > > > (tgdb) p b->related_breakpoint > > > $2 = (struct breakpoint *) 0x83b49d0 > > > > > > Then at breakpoint.c:6721, I print the breakpoint to be deleted > > > (tgdb) p bpt > > > $3 = (struct breakpoint *) 0x83b49d0 > > > > > > This is the related_breakpoint! > > > > > > at the end of breakpoint_delete I do > > > (tgdb) p breakpoint_chain->next->next->next->next->next->next > > > $30 = (struct breakpoint *) 0x83b4878 > > > > > > (tgdb) p breakpoint_chain->next->next->next->next->next->next->related_breakpoint > > > $32 = (struct breakpoint *) 0x83b49d0 > > > > So far, actually, so good - but is this still true when > > breakpoint_auto_delete returns? Why isn't the other one deleted too? > > What's its "disposition" at this point? > > Yes, > > (tgdb) p breakpoint_chain->next->next->next->next->next->next > $47 = (struct breakpoint *) 0x83b4878 > (tgdb) p breakpoint_chain->next->next->next->next->next->next->disposition > $51 = disp_donttouch > (tgdb) p breakpoint_chain->next->next->next->next->next->next->related_breakpoint > $48 = (struct breakpoint *) 0x83b49d0 > (tgdb) p breakpoint_chain->next->next->next->next->next->next->related_breakpoint->disposition > $49 = disp_del > > I don't know why this seems OK to you. I must be missing something. > breakpoint_chain->next->next->next->next->next->next->related_breakpoint > was a pointer to a breakpoint that was deleted. Thus, the pointer is > invalid. The reference to the deleted breakpoint (related_breakpoint > field) must be set to NULL somehow. Both of them should have the same disposition at this point. That's why it's OK. They should always be deleted together; they should have had disp_del_at_next_stop. We are deleting the scope breakpoint because the watchpoint has gone out of scope; 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. That's presumably the bug. Why it never hit before, I have no clue. Eli, you know a lot about the watchpoint mechanism; do you know how this is supposed to work? > It seems that whenever a breakpoint is deleted, all other > breakpoints related_breakpoint field needs to be checked, to see if they > pointed to the data that was just deleted. > > 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. -- Daniel Jacobowitz CodeSourcery, LLC