Disabling a break point deletes it

[sj-raima]

Disabling a break point by unchecking the toggle box to the left in the breakpoints window deletes the break point instead of disabling it. Only clicking the trash can is supposed to delete the break point.

Doing "info breakpoints" in the debug console indeed shows that the break point has been deleted.

I can manually disable and enable the break point in the debug console with the expected behavior except that the UI is not updated to reflect this.

I hope that this behavior is not intentional and will be fixed.

Additional information follows:

midas v0.19.11 Pre-Release

   {
        "name": "Replay (midas-rr)",
        "type": "midas-rr",
        "request": "attach",
        "use-dap": true,
        "trace": "Full",
        "setupCommands": [
            "set debuginfod enabled off",
            "set auto-load safe-path /"
        ],
        "stopOnEntry": true
    },

$ /opt/binutils-gdb/bin/gdb --version GNU gdb (GDB) 14.1.90.20231220-git Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.

$ /opt/binutils-gdb/bin/gdb --config This GDB was configured as follows: configure --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-auto-load-dir=$debugdir:$datadir/auto-load --with-auto-load-safe-path=$debugdir:$datadir/auto-load --with-expat --with-gdb-datadir=/opt/binutils-gdb/share/gdb (relocatable) --with-jit-reader-dir=/opt/binutils-gdb/lib/gdb (relocatable) --without-libunwind-ia64 --without-lzma --without-babeltrace --without-intel-pt --without-xxhash --with-python=/usr --with-python-libdir=/usr/lib --without-debuginfod --with-curses --without-guile --without-amd-dbgapi --disable-source-highlight --enable-threading --enable-tui --without-system-readline --with-separate-debug-dir=/opt/binutils-gdb/lib/debug (relocatable)

("Relocatable" means the directory can be moved with the GDB installation tree, and GDB will still find it.)

$ /opt/rr/bin/rr --version rr version 5.7.0

[theIDinside]

Thanks for adding this issue. I believe this is a bug introduced by Midas custom DAP "interpreter". I remember having to do a real hacky solution since VSCode doesn't actually make a distinction between a disabled breakpoint and a deleted (nor is that encoded into the Debug Adapter Protocol spec, either, unfortunately). That being said, it should be fixable.

Could you try setting use-dap to false in launch.json and see if you witness the same behavior? I've been able to reproduce this issue locally, and also seen it go away by setting use-dap to false (however, it's not recommended to turn off use-dap, but testing it and seeing the same resulsts would strengthen my belief that the bug is in the new interpreter).

[sj-raima]

Setting use-dap to false works better but is still not entirely correct in my opinion.

Disabling it by unchecking the box also deletes the break point instead of disabling it. However, the break point is kept in the list. Checking the box recreates the break point again. This means that the break point number/ID will not be preserved.

[theIDinside]

Setting use-dap to false works better but is still not entirely correct in my opinion.

Disabling it by unchecking the box also deletes the break point instead of disabling it. However, the break point is kept in the list. Checking the box recreates the break point again. This means that the break point number/ID will not be preserved.

Yeah, this unfortunately is a problem with the Debug Adapter Protocol, as it has no notion of disabled/enabled breakpoints, it only understands set breakpoints.

VSCode sends the same DA-request for a "disable breakpoint" (i.e. unchecking) as it does for a "delete breakpoint" (i.e. the X/trash can button). This is not VSCode's fault though, the protocol itself unfortunately hasn't been designed with this in mind (and probably, a PR/RFC for the protocol repository should be sent here, that adds an enabled field to the SourceBreakpoint type here)

The best thing that can be done here, is the old functionality, until the debug adapter protocol provides a way to signal enabling/disabling of breakpoints.

[sj-raima]

I tested your claim with cppdbg. Same issue there. So, this is the best we can do and probably OK for most user, including me (in most cases). Thanks for quick response.

[sj-raima]

Thank you for a quick fix. I have verified this. Your "executive decision" makes sense. Again, thank you.