Is it possible to know which lines of the source code were executed?

I am debugging a C/C++ code with Visual Studio. There is a loop called 10000 times and in one of the interactions, at the end of the loop, there is an error, as the program tries to access the N+1 value of an array of length N. I want to go back and debug the origin of the error and I wonder if somehow Visual Studio, in debugging mode, can highlight visually or tell me which lines of the source code were executed. Then it 开发者_如何学Gowould be easier to find the error. Does anybody know if this is possible?

If this is not possible with VS, what other approaches could do this?

Thanks

EDIT: I also wonder if this could be done with any other IDE (Eclipse, Xcode, command line, etc)

put a conditional breakpoint where the array access is happening. That way your program will break on the N+1th access and you'll have the complete stack trace to work with.

If you know how many iterations you have to make (in this case 10,000), surely you can insert a hit-count on the loop for n (one prior to the error) and then step-through the next iteration using Intellisense to give you information as to what may be causing the problems?

Do you have any code we can see that might help us help you?

intellitrace in vs2010 can do this

http://msdn.microsoft.com/en-us/magazine/ee336126.aspx

I don't know of any such tool, but a substitute would be to print a distinct message within each conditional.

if(somethingThatMightNotHappen) {
    printf("This happened.\n");
    ...
}

No, the VS Debugger doesn't allow you to move backwards through time.

However, have a look at conditional breakpoints. You could break when the loop is run the Nth (or N-1th or whatever) time or when a specific condition is met (like variable idx > 1000) and step through the code.

If you set up code profiling in Visual Studio, you can configure it to provide code coverage information which will give some of the information you are looking for, but it won't help solve the problem.

The approach I would take would be to reduce the count of the loop to a manageable number (say 10) and step through the code. If you know what you expect to happen, I have found that stepping through code and verifying that it's performing the operations you expect for a small test set clarifies any strange behavior.

In my experience, nothing beats predicting what the computer will do and then verifying you both agree. The most common causes would be:

• Your condition is LESS THAN OR EQUAL instead of LESS THAN
• You test for one more than you expect
• your array is one smaller than you expect
• you start counting at 1 and loop through the number of elements

Off-by-one (the last three) is just about the most common mistake in algorithms.

The unit test framework will do what you want. You'll need to create a unit test that runs the function you want to call. Then, edit your test run configuration to enable code coverage.

Finally, once you've run your unit test (which can be just a single line of code to execute a function), go to the "Code Coverage Results" window and select the "Show Code Coverage Color" option. The code that executed will be colored blue and the code that didn't execute will be colored red.

Nifty, eh?

Update In response to the comment about C++, I do believe that this functionality works with C++, but I've never used it. Try right-mouse clicking on the code that implements the function you want to test code coverage for. There should be an option that says "Create Unit Tests". Be sure to build the code before doing this.

Try to catch the Exception! Simply put the code inside of a the loop into a try-block followed by a catch-block with a breakpoint in it.

Some of these debugging techniques have already been mentioned and I can't guarantee that all work with C++ but ScottGu has a nice list of good tips in his blog post.

I suppose you know about this already but it sounds to me like you're looking for the call stack tab in debug mode. You can use the Hit Count or Conditional debugging mode in the loop and when the error appears you go back down the call stack to where the data came from and set a few break points. Then you can run your program again and inspect how the data is built.