Thread: suggest me

http://www.cprogramming.com/tutorial/ maybe?
Maybe not debugging, but for other things, at least.

A "non-debugging" debugging technique is to start small - don't try to write tons of code at once, then hope that it all works. With more experience you can get away with writing a bit more, but it's often better to do small portions, debug that, then write another bit, debug that, write some more, debug that, and so on, until the code is complete.

Otherwise, debugging comes into three parts:
1. Finding the faulty code.
2. Fixing the faulty code.
3. Validating the fix.

#1 is usually the big portion, but #3 can be a major portion of work too in some cases, and #2 is almost always the smallest part.

There are many methods, and usually there isn't "one method works for all". Some of those methods are:
1. Defensive coding. To avoid bugs in the first place, or at least catch bugs EARLY [because a bug that has been "going along happily" for 20 function calls make it much harder to find], you should add statements such as "assert()" to catch things such as NULL-pointers, array indices out of bounds, negative numbers where you don't expect them, divide by zero, and anything else you "don't expect". Always have a "default" in switch statements, and if you have a if/else if/else chain, even if you THINK you have covered all possibilities, add an extra one to check for "none of the above". Preventing a potential bug from "getting loose" will save you time in the long run.

2. Printlining - adding printf/cout statement to show where in the code you are, and what the values of critical variables are.

3. Logging - similar to printlining, but a more permanent fixture in the code. Basicly, all functions [or all major functions] are set up with output statements that print important data to a logfile [or sometimes a serial port or similar]. Often logging is disabled by default, and enabled when you are looking for a problem.

4. Splitting the code in portions - this helps identify a problem. Basically comment out or otherwise "don't use" some portions of code and see if that eliminates the problem. If it does, then you know that the commented out code is the problem. If it still persists, comment out some OTHER code and see if that helps. Hopefully, eventually, you will end up with ONE function [or a small portion of a function] that has the bug in it.

5. Using a debugger to single-step, breakpoints and looking at variables. This is powerful as long as you have a good idea where to start looking. Many debuggers will also give you a good stack-trace (aka call-stack), showing which functions have been called to get to the point of the crash.

One technique for using a debugger to identify the code that crashes is to "step over" functions until you hit the one that crashes. Then start over, mark that one with a breakpoint, run until that function, then step into that function. Repeat this process until you find the actual faulty function, then step through that function until you find the problem.

Sometimes finding a problem with stepping is not possible - you may have to step millions of times to get through a function that draws a full screen pixel by pixel for example. In this case, you may want to find out "where it goes wrong", e.g. when x = 1024 and y = 760, and add an extra if-statement that you can set a breakpoint in. Using printlining to find the point of failure is one way that works here.

6. Code review. If you have a decent idea of which function is wrong, you can just read the code, perhaps also using pen and paper to follow the code step by step. Pay particular attention to "edges", e.g. where loops end, if-statements and calculations at the upper or lower range of the value-range you expect.

--
Mats

gcc's -g switch tells the compiler to generate "debug info".
This is used when you run the application in the debugger, e.g. gdb, allow you to see variables (by giving the debugger info about where each variable is stored) and connect the machine code that the compiler generates with the source-code that you wrote, so that when you say "Break func1" it knows where func1 is in the machine-code and can put a breakpoint on that address. It then uses this information for "stepping" to know where the next line of code is, etc, etc.

--
Mats