


  MS Visual C++ Conditional Breakpoints
  Submitted by

There haven't been any tips for a while, so I thought I'd share this feature I found the other day.

I have a single class that implements a byte stream used all over the place which transfers data in a separate thread. This thread moves all the data streams along their merry way (i.e. there's one static thread, not one thread for each object). Wouldn't you know it, I had a bug I had to track down even though I thought the code was solid. The problem was that I had to have at least 10 instances of this class to even run the program, and everything was happening in a different thread at a 10ms interval, so I couldn't just set a breakpoint in a method because it'd be impossible to track. Enter conditional breakpoints:

[Note: this only applies to Microsoft Visual C++, sorry]
What you do is set a breakpoint where you normally would (F9). Now, edit breakpoints (Alt-F9). Select the breakpoint you just created, and hit the "Condition" tab to bring up the "Breakpoint Condition" dialog. There are a couple things you can do from this dialog. The most useful is that you can set a condition for the breakpoint.

For my problem, I set a breakpoint where I created the byte stream that I thought was causing the problem. I noted its address in memory. Then I went into the class code for my worker thread, and set a breakpoint with the condition "pByteStream == 0xAEF38201" (or whatever the address was of the offending stream) . Then I continue execution. Like magic, the worker thread breaks when it gets to my offending stream, ignoring all the others. I also used this to put breaks in the byte stream code itself with the condition "this == 0xAEF38201".

(Another nice thing is that, at least in debug builds, your program always allocates variables in the same place in memory if you follow the same execution path; you only have to manually check the address once).

The other options in this dialog allow you to declare the size of a dereferenced void pointer to use with a the compare logic, and allow you to set a number of times to skip the breakpoint before actually breaking (so you can look at the execution every Nth loop).

Granted, this is all documented and not a "secret", but it's something I'd never discovered until my back was against the wall. Hope this helps with your debugging.



Please read our Terms, Conditions, and Privacy information.