From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16281 invoked by alias); 29 Mar 2005 01:35:53 -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 16060 invoked from network); 29 Mar 2005 01:35:36 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 29 Mar 2005 01:35:36 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DG5ek-0001iU-ID for ; Mon, 28 Mar 2005 20:36:35 -0500 Date: Tue, 29 Mar 2005 01:35:00 -0000 From: Daniel Jacobowitz To: GDB Subject: Re: [mi] watchpoint-scope exec async command Message-ID: <20050329013634.GB6373@nevyn.them.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050329014203.GB3801@white> User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-03/txt/msg00273.txt.bz2 On Mon, Mar 28, 2005 at 08:42:03PM -0500, Bob Rossi wrote: > > > My hunch is that b->related_breakpoint's memory was free'd and never set > > > to NULL. Is this possible? I don't think a watchpoint would pick that > > > up, would it? > > > > No, but valgrind would. Anyway, a breakpoint on delete_breakpoint > > would probably catch this also. > > > > I can't imagine how that would happen though. > > Yeah, this appears to be what is happening. With a little help, we could > probably squash this bug. You need to follow some of these pointers to figure out what's going on. > 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? -- Daniel Jacobowitz CodeSourcery, LLC