2

I am using VSCode to debug a C++ code.

The code is running using an attach configuration (Python C++ Debugger VSCode extension).

When running the code, the debugger stops at a point where there is no breakpoint.

It seems there is a breakpoint set that is not visible in VSCode editor (and breakpoints panel). How can I find and clear that?

moriaz
  • 96
  • 6
  • 1
    If it stops at a point where there is _no_ breakpoint, how will you "remove a breakpoint"? There is nothing to remove! Look in the breakpoint list in the left sidebar in the debug view. If it's not there, and there's not breakpoint indicator in the gutter where it stops there, there's "no breakpoint" and something deeper is wrong (Ex. a bug with the debug extension). – starball Apr 27 '23 at 10:08
  • Exactly. There is nothing neither in the gutter nor in the sidebar. The extension does nothing special. It just starts gdb. So, there should be something related to gdb and VS Code. – moriaz Apr 27 '23 at 11:29
  • I had the same problem with debugging a Microsoft Business Central extension. The point it stopped was where it failed to retrieve a record from the database. It didn't show any hint in the debugger, but indeed it stopped there for a reason. – Roeland Apr 27 '23 at 12:11
  • Did you do anything like this? https://stackoverflow.com/q/1115428/11107541 (make gdb break on thrown exceptions?) If so, see https://stackoverflow.com/q/31069780/11107541. – starball Apr 27 '23 at 21:26
  • when this happens, is it for breakpoints in a shared library that you set before starting the program ad loading those libraries? Or does it happen in other cases too? – starball Aug 30 '23 at 17:49

2 Answers2

1

I found the solution to my problem.

Method 1: It can be applied when the debug session is active and a breakpoint (not the invisible one) has been hit.

  • Open the Debug Console in VS Code. It's a panel/tab that by default opens at the bottom of the editor next to the integrated terminal.
  • Use the command line at the bottom of the panel to run the following commands.
  • Run "-exec info breakpoints" to list the active breakpoints. You will see some breakpoints that are in the list but not in the breakpoints tab of the debugger toolbar.
  • Run "-exec delete breakpoints 6" to delete a specific breakpoint, 6 in this example.
  • You may also run "-exec help breakpoints" to find more commands related to breakpoints.
  • Note that when the debug session restarts, the breakpoint is added again.

Method 2: Clear all the breakpoints by clicking on the small x button on the top right of the Breakpoints panel: Remove All Breakpoints. This will clear the invisible breakpoints as well.

moriaz
  • 96
  • 6
0

The same issue has been bothering me for some time as well, but with over 60 breakpoints I don't want to just clear them all. Here are a couple more details that I use.

When debugging, switch from OUTPUT or TERMINAL to the DEBUG CONSOLE. When the invisible breakpoint is hit, gdb tells you what its breakpoint number is. Note that sometimes there are multiple breakpoints in the same location (which you can see by typing -exec info breakpoints and it will report <MULTIPLE>). In this case, make sure you -exec delete breakpoint N and not just the "sub-breakpoint" N.M, because the others will still trigger it.

Sometimes the breakpoint is hit when the program first starts. In this case, click on each of your active breakpoints in the BREAKPOINTS panel. If any of them are set on a block of code that is commented out this will cause the program to halt at startup. You can disable or remove this breakpoint from either the GUI panel or from the gutter in the code editor (right-click to select to disable).

I'm still waiting for a solution that prevents the invisible breakpoints from being set again without having to "clear all". For me, the problem (with <MULTIPLE> breakpoints, anyway) seems to happen when the breakpoints are set in template<T> logic. This is possibly a bug in the VSCode C++ parser, and may be made worse when you set the breakpoint while the code is currently in a state where it fails to compile.

rand'Chris
  • 788
  • 4
  • 17
  • when this problem happens for you, is it just for breakpoints in a shared library that you set before starting the program ad loading those libraries? Or does it happen in other cases too? – starball Aug 30 '23 at 17:49
  • @starball In my circumstance, no shared libraries are involved. – rand'Chris Sep 01 '23 at 14:06