As mentioned in an earlier post, we will be writing about all of the different breakpoint functionality available in Visual Studio.  In this first part, we discuss the hit count breakpoint.  If you wish to follow along, the code samples below are available for download.

Sample Problem

Consider the following method that applies a basic shift cipher to a string. A shift cipher (or Caesar cipher) simply shift the letters of a message by a fixed amount.

clip_image001

We have a breakpoint set on the return statement of the method. Now let’s see what happens when we run the following code:

clip_image002

When we are stopped at the breakpoint, we inspect shiftArray and see that we have a problem.

clip_image003

While the rest of the encoded message does not make it obvious that there is a problem, we can see that we have ‘{‘ in the 35th position, which is obviously wrong. We suspect that the problem is in the loop that is encoding each letter, but we really want to examine the 36th iteration of the loop. If we just set a breakpoint in the loop, we would have to sit there and continue it 35 times before we can really get down to debugging. This is where using hit count breakpoints comes in handy.

Creating the Hit Count Breakpoint

To create the hit count breakpoint, first start by simply creating a regular breakpoint in the loop you want to examine.

clip_image004

Then right click on the breakpoint to bring up the context menu.

clip_image005

And click on “Hit Count…” to bring up the Hit Count configuration dialog.

clip_image006

Now change the setting in the dropdown from “break always” to “break when the hit count is equal to” and then enter 36 as the hit value.

clip_image007

After you click “OK” you’ll notice that the breakpoint now has a ‘+’ inside indicating that this is an advanced breakpoint.

clip_image008

Now when I start the application under the debugger, I stop right where the code is changing the value of shiftArray[35].

clip_image009

And as I step through, I can see the problem. First the letter is shifted off the end of the alphabet.

clip_image010

But then when I step again, I can see that it skips the code that is supposed to push the letter back into the alphabet range.

clip_image011

Now I have found my problem. The condition should be shiftArray[i] >= 123 instead of shiftArray[i] > 123. And I found this more quickly than I would otherwise by using a hit count breakpoint.

Skipping Ahead

Hit Count breakpoints can also be used when you need to skip ahead in the execution of your code, but you don’t quite know exactly how far ahead you want to go.

Consider the following recursive function that calculated the greatest common divisor (GCD) of two numbers.

clip_image012

As a developer, you may want to debug through this function in order to see the intermediate values during the GCD calculation. Given two large numbers, you know that this function is likely to run for a long time, but you don’t know quite how long. In this case you can use hit count breakpoints to save you some time.

As before, you can bring up the hit count dialog by right-clicking on the breakpoint and selecting “Hit Count…”

This time, select the “break when the hit count is greater than or equal to option” and enter a value of 10.

clip_image013

This will allow you to skip through the first 10 calls to the function to get closer. Now consider calling the function with the following two integers,

clip_image014

Running to the breakpoint gets me down to small numbers for x and y so that I can follow the rest of the calculation.

clip_image015

And if I continue the application, the application will continue to stop at the breakpoint each subsequent time it hits it.

clip_image016

If I bring up the breakpoint hit count dialog again, you can see that I can view the current hit count for the breakpoint.

clip_image017

I can even click the reset button to avoid stopping on the breakpoint for another 10 iterations.

Counting Iterations

Finally, hit count breakpoints can also be used simply to count the number of times the breakpoint is hit. Let’s say we wanted to count the number of iterations in our GCD example. As a before, you want to create a hit count breakpoint and select the option “break when the hit count is greater than or equal to”. This time, instead of choosing a number to break on, instead choose an arbitrarily large number like 99999.

clip_image018

With a number this large, the breakpoint will never be hit. Now set another breakpoint somewhere after all of the iterations of GCD will already be complete. When you stop at this breakpoint, you can see the hit count in the Breakpoints window (available from the Debug -> Windows menu).

clip_image020

So you know that the program went through the GCD function 14 times.