This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [mi] watchpoint-scope exec async command
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