This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [mi] watchpoint-scope exec async command


[Sorry for a late response: I needed to refresh my memory of how the
related code works.]

> Date: Mon, 28 Mar 2005 21:01:23 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Eli Zaretskii <eliz@gnu.org>
> 
> We are deleting the scope breakpoint because the watchpoint has gone
> out of scope

Are you sure?  Bob didn't show enough backtraces for me to be sure,
but the one backtrace he did show seems to tell that we are deleting
the scope breakpoint because it's marked either disp_del or
disp_del_at_next_stop (and I'd like to know which of these two
possibilities actually happens there), not because the watchpoint has
gone out of scope (or at least not directly because of that).

Bob, could you please show the backtraces at every place where you
until now only posted the result of printing variables?  Also, please
put a breakpoint where GDB says a watchpoint has gone out of scope,
and show a transcript of a session where we could see the sequence of
the events: the watchpoint and/or scope breakpoint is hit, marked to
be deleted ASAP, then actually deleted.

> 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.

Sorry, I'm not sure I understand correctly what you are saying,
because of the ambiguous use of "it" and "its".  This sentence is the
most ambiguous for me:

> When we delete it we ought to be deleting its related breakpoint too
> (they point to each other).

Who is "it" here?  If it's the watchpoint, then I don't understand
your reasoning, because if the scope breakpoint rather than the
watchpoint itself triggered, we don't delete anything.

> That's presumably the bug.

Probably, but I'd like to see more information (from Bob) to be sure.

Let's not forget that software watchpoints also share some (most?) of
the code used for hardware data-write watchpoints.  I'm quite sure
that the scope breakpoint was invented for software watchpoints,
because hardware watchpoints simply don't need it: they incur no
overhead if they are not deleted, as long as they are not hit; and
once they are hit and we find them to be out of scope, we do TRT: mark
both the watchpoint and its related breakpoint for deletion at next
stop.  (I suspect that we don't delete them right away due to some
peculiarity of software watchpoints that are implemented by
single-stepping the inferior.)

Bob, could you also try the same program with a software watchpoint,
and see if you hit the same bug or not?  If the behavior is different,
please show where the GDB execution thread goes a different way and
how it avoids the crash.  (Forcing software watchpoints might not be
easy.  One way, on a x86 machine, is to watch a region that is more
than 16 bytes long.  Another way is to build a hacked version of GDB
that uses only software watchpoints.)

> > 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.

??? My interpretation of that comment is that a breakpoint/watchpoint
that was already deleted should have its type set to bp_none, and in
that case we don't delete it again.  What am I missing?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]