[Bug python/29603] Python Watchpoints are not deleted

["ssbssa at sourceware dot org" <sourceware-bugzilla@sourceware.org>]

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

Hannes Domani <ssbssa at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ssbssa at sourceware dot org

--- Comment #5 from Hannes Domani <ssbssa at sourceware dot org> ---
(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?

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