From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31269 invoked by alias); 29 Mar 2005 01:51:05 -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 30371 invoked from network); 29 Mar 2005 01:51:00 -0000 Received: from unknown (HELO lakermmtao04.cox.net) (68.230.240.35) by sourceware.org with SMTP; 29 Mar 2005 01:51:00 -0000 Received: from white ([68.9.64.121]) by lakermmtao04.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050329015058.JGYF11124.lakermmtao04.cox.net@white> for ; Mon, 28 Mar 2005 20:50:58 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1DG6nZ-00013K-00 for ; Mon, 28 Mar 2005 21:49:45 -0500 Date: Tue, 29 Mar 2005 01:51:00 -0000 From: Bob Rossi To: GDB Subject: Re: [mi] watchpoint-scope exec async command Message-ID: <20050329024945.GC3957@white> Mail-Followup-To: GDB 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050329013634.GB6373@nevyn.them.org> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-03/txt/msg00274.txt.bz2 > > 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. 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. Thanks, Bob Rossi