![]() |
Chapter 7 | ![]() |
At last, you get to find out what all those buttons were for on the debug bar!
The first thing we need to do though (as in all debugging) is take a guess where our program is failing. Though MSVC gives us a good hint, it may not always be accurate, the error may have occured in a previous frame, or even in previously executed code in the same function. It'd be nice to examine each potential spot if we don't know which is the culprit, and breakpoints allow you to do this. Breakpoints are your way of telling the debugger "I want to know what's happening there, so even though you haven't crashed, drop me into command mode so I can look around!" It's very useful, especially for non-crash bugs. In effect, your program will 'pause' at that spot. To examine them though, we're going to need a more complicated program than MSVCex1. Cut and paste this code into a file called MSVCex2.c:
#include <stdio.h> #include <stdlib.h> int bubblesort(int *array, int size); int main(int argc,char *argv[]) { int array[100]; int i; srand(1); for(i=0;i<100;i++) { array[i] = rand() % 300; } bubblesort(array,100); for(i=0;i<100;i++) { printf("%d\n",array[i]); } } int bubblesort(int *array, int size) { int i,j; int temp; for(i=0;i < size -1;i++) { for(j=0;j> array[j+1]) { if(array[j] > array[j+1]) { temp=array[j]; array[j] = array[j+1]; array[j+1] = temp; } } } }Once you get that copied in, compile it and run it through the debugger(F5). You'll notice that it runs quickly, pops open a dos window, and quickly exits without any errors. No problems here, but it goes by too fast to see what the heck it's doing! It's not feasible to put in logging messages; on an array of 100 items, a bubblesort performs 99^2 sort operations; even one log per gives you nearly 10000 entires.
Yeah, it's obviously a contrived example, but lets put in one of these breakpoints, just to see how they work. Go ahead and right click on the line "bubblesort(array,100);". This will cause a pop-up menu to ..erhm.. pop up. From the list of menu items, select "insert/remove breakpoint".
You should see a little red dot to the left of the line now, in the grey strip that runs the length of the window. It'll look like this:
Now, go ahead and run the code in debug mode again (F5). Notice how it stops right where you wanted it to?
Once it's stopped, you can do all sorts of things; examine the values of the variables, switch stack modes, even change the value of data in the program itself! Note though; if you put your breakpoint on an empty line, the program will not stop until it hits the next non-blank, non-comment line in the program. I can't see any way in which this will cause a problem; you'll be in the same stack frame, but it is something to know.
If you'd like to continue the process, just hit F5 (our debug button changes functions while the program is actively being run), or select
Debug Go. Of course, you may want to take the time to play around, change values, and generally muck things
up.
![]() |
Index | ![]() |
7.4.3 Examining the Stack | 7.5.2 Advanced Breakpoints |