This page provides troubleshooting instructions for issues with the GDB break-in mechanism. If the break-in mechanism is not working, you would be typically able to set breakpoints before starting a debug session or while already stopped at another breakpoint, but not while the program is running.

This happens because setting or removing breakpoints while the program is running involves temporarily stopping the debug session without waiting for it to hit a breakpoint. This is normally done by sending a Ctrl-C event to either GDB or the GDB stub (e.g. gdbserver or OpenOCD).

While it works out-of-the-box in most cases, some tools may not support it, or may work unreliably. If you are experiencing issues with the break-in mechanism, follow the steps below to troubleshoot it.

Break-in Never Works

If the break-in functionality never works (i.e. it’s not possible to set breakpoints while the program is running), the low-level tool used for debugging (gdb stub) might be ignoring the Ctrl-C events sent by VisualGDB. If you are debugging a Linux program, see the documentation for configuring break-in logic for Linux targets.

If your debugging setup involves a gdb stub (such as OpenOCD), the break-in requests could be sent either directly to the gdb stub, or to the gdb debugger that forwards them to the stub. Furthermore, if the stub (or GDB) is running on Windows, the break-in can be requested by sending either a Ctrl-C or a Ctrl-Break event. Sending Ctrl-C events to gdb (and having it forward them to the stub) should work in most cases, however if it doesn’t work, you can try other combinations of modes via VisualGDB Project Properties -> Debug Settings -> Custom GDB Stub: You can also override the break-in mode via VisualGDB Project Properties -> Custom Debug Steps (requires Custom edition or higher):

Break-in Works Unreliably

If the break-in functionality works unreliably, it could be caused by race conditions inside the GDB stub. They can be worked around via one of the methods shown below.

Enabling Async Mode

If the break-in functionality it working intermittently, you try enabling the asynchronous gdb mode via VisualGDB Project Properties -> Advanced GDB Settings:

Asynchronous mode uses a different mechanism for requesting gdb break-ins, so it may sometimes work around gdb stub bugs.

If enabling the asynchronous mode results in error messages while trying to set breakpoints, try disabling the “asynchronous mode supports breakpoints commands while the target is running” setting.

Enabling session stop consolidation

Session stop consolidation reduces the number of break-in requests issued in short succession. Instead of resuming the session immediately after a breakpoint has been modified, VisualGDB can wait the specified amount of milliseconds in case Visual Studio requests other actions that require stopping the session. In this case, instead of stopping and resuming the session multiple times, it will be only stopped and resumed once. You can configure it via VisualGDB Project Properties -> Advanced GDB Settings:

Adding Delays Between Resuming and Break-ins

Another source of intermittent issues with GDB break-ins is when VisualGDB tries to stop a debug session almost immediately after it has been resumed from the previous stop. If the other workarounds do not help, try setting the Tools->Options->VisualGDB->General->Debug->Minimal delay before an immediate break-in request option to 500 milliseconds or higher. If this option is set, VisualGDB will wait before issuing a break-in request if it came too soon after resuming the session