Re: [mi] watchpoint-scope exec async command

[Daniel Jacobowitz <drow@false.org>]

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