Breakpoints
Breakpoints are special markers that suspend program execution at a specific point. This lets you examine the program state and behavior. Breakpoints can be simple, for example, suspending the program on reaching some line of code, or involve more complex logic, such as checking against additional conditions, writing to a log, and so on).
Once set, a breakpoint remains in your project until you remove it explicitly, except for temporary breakpoints.
note
If a file with breakpoints was modified externally, for example, updated through a VCS or changed in an external editor, and the line numbers have changed, breakpoints will be moved accordingly. Note that CLion must be running when such changes are made, otherwise they will pass unnoticed.
The following types of breakpoints are available in CLion:
Line breakpoints: suspend the program upon reaching the line of code where the breakpoint was set. This type of breakpoints can be set on any executable line of code.
Exception breakpoints: suspend the program when the specified exception is thrown. They apply globally to the exception condition and do not require a particular source code reference.
Symbolic breakpoints: suspend the program when a specific function or method are executed.
When a debug session hasn't started yet, all line breakpoints are marked the same way:

During a debug session, CLion detects the breakpoints statuses and changes the markers accordingly:
Line breakpoint is successfully resolved by the GDB or LLDB debugger using the provided debug symbols. Such breakpoint can be hit during execution:
Line breakpoint is invalid, which means it can’t be resolved by GDB or LLDB and will never be hit. This can happen when the breakpoint is located out of the executable code or some debugging symbols are missing. CLion detects such situations accurately and updates the icon on the fly (for example, the status will change when you load the proper debug symbols).
Click the gutter at the executable line of code where you want to set the breakpoint. Alternatively, place the caret at the line and press CtrlF8.
While in disassembly view, you can set breakpoints the same way you do in the source code. See Breakpoints in disassembly.
Press CtrlShiftF8 or select Run | View Breakpoints from the main menu.
In the Breakpoints dialog, press AltInsert or click
, and select Exception Breakpoints or JavaScript Exception Breakpoint.
Click View Breakpoints
in the left part of the Debug tool window or press CtrlShiftF8.
In the Breakpoints dialog, press AltInsert or click
, and select Symbolic Breakpoints.
Specify the symbol name and select whether you want this breakpoint to be hit in all modules, or in a specific module only.
For non-exception breakpoints the breakpoint in the gutter.
For all breakpoints: go to Run | View Breakpoints CtrlShiftF8 in the main menu, select the breakpoint, and click Remove Delete.
To avoid accidentally removing a breakpoint and losing its parameters, you can choose to remove breakpoints by dragging them to the editor or clicking the middle mouse button. To do this, go to Settings | Build, Execution, Deployment | Debugger and select Drag to the editor or click with middle mouse button. Clicking a breakpoint will then enable or disable it.
If you don't need to stop at your breakpoints for some time, you can mute them. This allows you to resume normal program operation without leaving the debugger session. After that, you can unmute breakpoints and continue debugging.
Click the Mute Breakpoints button
in the toolbar of the Debug tool window.
When you remove a breakpoint, its internal configuration is lost. To temporarily turn an individual breakpoint off without losing its parameters, you can disable it:
For non-exception breakpoints: right-click it and set the Enabled option as required. You can also toggle them with the middle mouse button if removing breakpoints is not assigned to it.
For all breakpoints: click Run | View Breakpoints CtrlShiftF8 and check/uncheck the breakpoint on the list.
To move a breakpoint, drag it to another line.
To copy a breakpoint, hold Ctrl and drag a breakpoint to another line. This creates a breakpoint with the same parameters at the destination.
You can view the list of all breakpoints in the Bookmarks tool window. Breakpoints are automatically added to the dedicated list in the tool window once you place them in your code.
In the main menu, go to View | Tool Windows | Bookmarks or press Alt02 and expand the Breakpoints list.
Depending on the breakpoint type, you can configure additional properties which allow you to tailor its operation for specific needs.
Basic breakpoint properties are available via intentions. Place the caret at the line with the breakpoint and press AltEnter:
More breakpoint options are available via the right-click context menu:
Click More or press CtrlShiftF8 to access the Breakpoints dialog:
In this chapter, you can find information on the features available for breakpoints.
Clear the checkbox to temporarily disable a breakpoint without removing it from the project. Disabled breakpoints are skipped during stepping.
You can configure CLion to enable/disable breakpoints on clicking rather than removing them altogether. To do this, go to Settings | Build, Execution, Deployment | Debugger and set the Remove breakpoint option to Drag to the editor or click with middle mouse button.
When this checkbox is selected, CLion uses the base name of the source file instead of its absolute path. This is closer to how you would specify the path in the debugger's command line interface.
Use this option for the cases when the debugger fails to resolve the absolute paths: when the program was compiled with -fdebug-prefix-map
or the source files were moved to a different location after building the binary and the required path mappings are missing.
The breakpoint will be set using only the file name in GDB or LLDB. This may lead to a situation where breakpoints match to several files with the same name, so the debugger will stop in all of these locations.
Specifies whether to pause the program execution when the breakpoint is hit.
Non-suspending breakpoints are useful when you need to log some expression without pausing the program (for example, when you need to know how many times a method was called) or if you need to create a trigger breakpoint that will enable dependent breakpoints when hit.
This option is used to specify a condition that is checked each time the breakpoint is hit. If the condition evaluates to true
, the selected actions are performed. Otherwise, the breakpoint is ignored.
note
The condition must be valid at the line where the breakpoint is set.
The result of the expression is taken from the return statement. When there is no return statement, the result is taken from the last line of code.
When evaluating expressions, make sure you are aware of their possible side effects as they may potentially affect the behavior and the result of the program.
When a breakpoint is hit, the following can be logged to the console:
"Breakpoint hit" message: a log message like
Breakpoint reached: HebrewCalendar.cpp:62
.Stack trace: the stack trace for the current frame. This is useful if you want to check what paths have led to this point without interrupting the program execution.
Evaluate and log: the result of an arbitrary expression.
The result of the expression is taken from the return statement. When there is no return statement, the result is taken from the last line of code, which doesn't have to be an expression: a literal works too. This can be used to produce a custom message or to keep track of some values as the program executes.
When evaluating expressions, make sure you are aware of their possible side effects as they may potentially affect the behavior and the result of the program.
(optional) If the expression that you want to log is in front of you in the editor, select it.
Hold Shift and click the gutter.
When a breakpoint is selected in the Disable until hitting the following breakpoint box, it acts as a trigger for the current breakpoint. This disables the current breakpoint until the specified breakpoint has been hit.
You can also choose whether to disable it again after this has happened or leave it enabled.
This option is useful when you only need to suspend the program under certain conditions or after certain actions. In this case, the trigger breakpoint usually isn't required to stop the program execution and is made non-suspending.
- Use breakpoints for debug printing
Use non-suspending logging breakpoints (sometimes referred to as watchpoints in other debuggers) instead of inserting print statements in your code. This provides a more flexible and centralized way of handling debug log messages.
- Set logging breakpoints more quickly
To set a non-suspending logging breakpoint, hold Shift and click the gutter. This will not suspend the program execution and instead log a message like
Breakpoint reached
. If you want to log some expression that is in front of you in the editor, select it before holding Shift and clicking the gutter.- Add breakpoint descriptions
If you have many breakpoints in your project, you can add descriptions to breakpoints for ease of search. To do this, right-click a breakpoint in the Breakpoints dialog CtrlShiftF8 and select Edit description from the menu. Now when you start typing the breakpoint name, it gets the focus.
Thanks for your feedback!