Debugging a program

[herby490]

When I am writing a program I always see options for debugging a program and I have no idea what they do. Do they just check to see if you made any errors in your program i.e. forgetting to put a semicolon. I also see that "program debug databases" are created in the folder of the program but I am unable to do anything with them. So my question is what does debugging actually do and how do you use it. If it makes any difference I am using Visual C++ 2008(if I can figure out how to redistribute programs) or Code::Blocks with Mingw(if I can't figure out how to redistribute VC++ programs).

[Kros]

I'm not terribly familiar with using debug releases to remotely debug issues, someone else can handle that subject if they know more on it.

What debugging is though, in general, is the process of resolving run-time errors. Or, bugs that aren't caught at compile time. Compile time errors are ones like syntax errors (missed a semicolon).

You do this with tools built into your IDE, such as breakpoints. Setting a breakpoint in your IDE tells the program to pause execution at a certain point, and let you take a look under the hood at things. During this pause you can look at what variables are currently set to, and step through your code one chunk at a time.

To do this in visual studio (I'm not familiar with Code::Blocks), navigate to someplace in your code where you'd like execution to stop, click somewhere on that line and hit F9, it'll toggle a breakpoint there. You can also just click-toggle them in the little left hand margin. After that, run as normal (F5), once you've hit the breakpoint, open up the debug drop down to see a few of the different things you can do.

Theres other stuff you can do that I'm less familiar with; someone else will surely add to this.

[CC Ricers]

In Visual Studio you also have a Call Stack feature (I believe something similar is also in Code::Blocks) for tracing back any points where the program may have crashed. So if you get a run-time error, the Call Stack gives some good clues as to where the error occurred, and it's usually in the last function that was listed from the stack.

You can also work backwards through the stack to find the entry point that led to the faulty execution of a function, and the entry point to that, and so on. Because the function that caused the crash may not create an error all the time, but only under certain conditions, the list of events can help you see how these conditions were created.

[MarauderIIC]

Debugging essentially lets you go line by line through your all of your code (or just certain sections, if you so wish) and check that it does what you expect it to at every line, therefore, you can tell exactly when something goes wrong -- helps you pinpoint that bad line of code that messes up your program.

In other words, if you do:

Code: Select all

myNum = -2;
while (myNum < 0) {
    myNum--;
}

And you notice it's an infinite loop (which you would find out when you run in debug mode and then tell debug to stop/pause/it hits a breakpoint, it would say "I STOPPED HERE!!")

And then you set what's called a "watch" on myNum, you could check the value of myNum at every line. Hopefully you would eventually notice that myNum is decreasing, and since it was already < 0... yeah, you just found why your loop is infinite.

Also, if your program crashes, you can doubleclick on the top entry in the call stack and see what line it crashed on. Although, this might not be your code, so you might need to go a bit farther down. Say you check each entry on the call stack and you find that the first line of code that it points to that is YOURS is:

Code: Select all

SDL_Free(screen)

. Well, then you would hopefully be suspicious that this call is what's causing your program to crash. So, you might check to see if "screen" has already been freed. Or, you might check to see if "screen" is the initial screen (which SDL frees automatically, IIRC). Then you would adjust your call as needed. Bad pointers are a lot harder to find without debugging :)

Those are the basics, anyway. My recommendation is to fiddle around.

[sparda]

Debugging is actually pretty neat. If you're ever using GNU/Linux/UNIX (I think even MinGW for windows, I'm not 100% sure though), you can use GDB, which is a command line debugger. When you compile your program, you must tell gcc (or g++) that you'll be debugging for it with the -g flag:

Code: Select all

gcc -g main.c -o main

Then, just start up the gdb with the program name

Code: Select all

gdb main

From there you can do a slew of things, like set breakpoints or run the program. Check out the official documentation for more details.

[herby490]

Ok I decided to play around with the debugger in Code::Blocks because I am sick of not knowing how to redistribute in VC++. That point aside I ran the debugger and a window came up saying I segfaulted my program and opened the call stack which had the address, function, file, and line of the bad line of code. I then opened up other windows and they had things that i could not understand. For example the disassembly window had random letters and numbers in the first and last column and words in the middle column. How do I use this to debug my program.

[MarauderIIC]

Personally, I just sort of pretend it doesn't exist since I don't really know assembly :D

[dandymcgee]

Personally, I just sort of pretend it doesn't exist since I don't really know assembly :D

^ Excellent advice (unless of course you know assembly).