[Bug python/29603] Python Watchpoints are not deleted

["j3.soon777 at gmail dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29603

Johnson Sun <j3.soon777 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #6 from Johnson Sun <j3.soon777 at gmail dot com> ---
(In reply to Hannes Domani from comment #5)
> (In reply to Sourceware Commits from comment #4)
> > The master branch has been updated by Simon Marchi <simark@sourceware.org>:
> > 
> > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;
> > h=6e96d8a9702d1fef3eb6de47bb84bdea578eb1bb
> > 
> > commit 6e96d8a9702d1fef3eb6de47bb84bdea578eb1bb
> > Author: Johnson Sun <j3.soon777@gmail.com>
> > Date:   Thu May 11 23:46:20 2023 +0800
> > 
> >     Disable out-of-scope watchpoints
> >     
> >     Currently, when a local software watchpoint goes out of scope, GDB sets
> >     the watchpoint's disposition to `delete at next stop' and then normal
> >     stops (i.e., stop and wait for the next GDB command). When GDB normal
> >     stops, it automatically deletes the breakpoints with their disposition
> >     set to `delete at next stop'.
> >     
> >     Suppose a Python script decides not to normal stop when a local
> >     software watchpoint goes out of scope, the watchpoint will not be
> >     automatically deleted even when its disposition is set to
> >     `delete at next stop'.
> >     
> >     Since GDB single-steps the program and tests the watched expression
> >     after each instruction, not deleting the watchpoint causes the
> >     watchpoint to be hit many more times than it should, as reported in
> >     PR python/29603.
> >     
> >     This was happening because the watchpoint is not deleted or disabled
> >     when going out of scope.
> >     
> >     This commit fixes this issue by disabling the watchpoint when going out
> >     of scope. It also adds a test to ensure this feature isn't regressed in
> >     the future.
> >     
> >     Calling `breakpoint_auto_delete' on all kinds of stops (in
> >     `fetch_inferior_event') seem to solve this issue, but is in fact
> >     inappropriate, since `breakpoint_auto_delete' goes over all breakpoints
> >     instead of just going through the bpstat chain (which only contains the
> >     breakpoints that were hit right now).
> >     
> >     Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29603
> >     Change-Id: Ia85e670b2bcba2799219abe4b6be3b582387e383
> 
> Can this be closed?

Yes, this can be closed. Thank you for the reminder.

-- 
You are receiving this mail because:
You are on the CC list for the bug.