Re: [mi] watchpoint-scope exec async command

[Daniel Jacobowitz <drow at false dot org>]

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