DBX vs. Visual Studio and WinDbg: Part 2D, Conditional Breakpoints
Join the DZone community and get the full member experience.Join For Free
This is where we are through the series:
- Calling a function
- Configuring breakpoints
- Setting multiple breakpoints at once
- Memory access breakpoints
- Memory access breakpoints, revisited
- Conditional breakpoints [this post]
- Tracing execution
- Execution control
- Displaying data, including STL collections
- Runtime application checking
- Miscellaneous commands
Today’s post is about configuring conditional breakpoints. Finally, this is one area where the Windows tools have feature parity with DBX, at least as far as the basic feature goes.
A conditional breakpoint is a breakpoint that is associated with a condition. If the condition is true, the debugger stops at the breakpoint; otherwise, it continues execution. The important question, then, is what kinds and shapes of conditional breakpoints are available, and how the expression evaluator copes with complex conditional expressions.
DBX makes it rather easy to specify a conditional breakpoint. Append –if at the end of any stop command and you have yourself a condition that applies to anything in the scope of the breakpoint. For example:
stopped in main at line 15 in file "stl.cc" 15 global = 1; (dbx) stop at 22 -if v.size() == 2 (7) stop at "stl.cc":22 -if v.size() == 2 (dbx) cont stopped in main at line 22 in file "stl.cc" 22 m = v; (dbx) status (6) stop infunction main *(7) stop at "stl.cc":22 -if v.size() == 2
Visual Studio has conditional breakpoint support—when a breakpoint is set, you can specify a condition that must be true for the debugger to stop. Unfortunately, these conditions are subject to even more stringent limitations than the expressions you can input in the Immediate Window. The trivial things, such as paramName > 13, still work, of course.
WinDbg circumvents the problem altogether by providing the ability to execute an arbitrary debugger command when a breakpoint is hit. Among the things that this debugger command may do is continue execution using the gc command; alternatively, it could display some output, stop, etc.
We have seen before an example of WinDbg’s conditional breakpoint support for implementing the stop inobject DBX command equivalent; I will not be repeating another example here.
Published at DZone with permission of Sasha Goldshtein, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Explainable AI: Making the Black Box Transparent
Demystifying SPF Record Limitations
Integration Architecture Guiding Principles, A Reference
Database Integration Tests With Spring Boot and Testcontainers