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


> Date: Tue, 29 Mar 2005 16:44:14 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: GDB <gdb@sources.redhat.com>
> 
> If the scope breakpoint triggers, we delete it.  From watch_command_1:
>           /* Automatically delete the breakpoint when it hits.  */
>           scope_breakpoint->disposition = disp_del;
> 
> That's what's happening in this case.  Then, shortly thereafter, the
> watchpoint triggers.  That's when we detect that it has gone out of
> scope, and set it to delete at next stop; and we crash, because we
> already deleted the scope breakpoint when it was hit.

I hoped to see this from Bob's tracebacks, but I only saw the first
part of what you describe: that the scope breakpoint is being deleted
after it triggers (not _when_, _after_: it is deleted by
breakpoint_auto_delete).

Assuming that the watchpoint triggers after that, it is marked as
disp_del_at_next_stop, so it would be slated for deletion by the same
breakpoint_auto_delete function when it is called shortly after.  This
is the part that I didn't see in Bob's session.  I will assume that
things indeed happen like you say: that when we try to delete that
watchpoint, we crash when we access its scope breakpoint, which was
already deleted and freed.

I think we have the following alternatives to fix this.  First, we
could stop using scope breakpoints for hardware-assisted watchpoints.
(The scope breakpoint is not needed in this case, since they don't
slow down the executable, and because we have an independent facility
to detect that a hardware watchpoint went out of scope: that is the
code run by insert_bp_location and watchpoint_check which prints a
warning about the fact that the watchpoint went out of scope.)
Software watchpoints do need the scope breakpoint (to stop
single-stepping the inferior once the watchpoint goes out of scope),
and in that case Bob's testing demonstrates that the scope breakpoint
machinery works correctly.  So we need to continue using scope
breakpoints for software watchpoints alone.

If we don't arrange a scope breakpoint for a hardware watchpoint, we
won't hit the problem Bob reported.

The second alternative is to treat scope breakpoints specially in
breakpoint_auto_delete: when we see a scope breakpoint that is marked
for deletion, we will have to find its watchpoint, and if that
watchpoint is a hardware watchpoint, we will have to delete that
watchpoint as well.

I like the first alternative better, since it seems cleaner.

As an aside, I'd ask Bob to run the same test program, but this time
use awatch instead of watch command.  I'd be interested to hear if the
same problems (i.e. memory write into a freed block reported by
valgrind and an occasional crash) happen in that case as well.  The
reason that I'm asking this is that we handle watch and rwatch/awatch
slightly differently, since the code that handles watch is run for
both software and hardware watchpoints.

> All the code surrounding bp_none is horribly bogus; we're walking freed
> memory if we hit it.

That's true, it sounds as if someone was not sure what our code does,
so he/she went over-defensive.

> I don't know if it still triggers today

I think Bob's testing shows that it does, for the software
watchpoints.

Did I help resolving this issue?


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