Originally Posted by Ajit Gunge
Hi Does anyone know how can one improve his debugging skills or how can one narrow down the problem and try to get to the solution ASAP.
You always want to divide and conquer when debugging. If you do not have access to a debugger, you want to put bread crumbs in your code to show you the execution path up to the point of failure.
I usually define a macro like this:
#define BREADCRUMB() \
fprintf(stderr, "%s:%n: bread crumb\n", __FILE__, __LINE__)
Then you can just copy and paste BREADCRUMB through your your entire code path. When you run your code, you will see the last bread crumb before it crashes or reports an error.
Then you can add more bread crumbs until you have bracketed the problem down to the exact line.
This method is very useful in debugging on embedded targets. On a desktop, you will almost always have access to a source level debugger which will allow you to put a break point before the code that fails. Then you just single step until you find the cause of the problem.
Fixing the actual error is a science unto itself. You need to have a very good understanding of pointers and how stacks work. Most bugs are caused by bad pointer arithmetic or stack overflow. If your bug is not one of those, it will usually be a bad argument to a function.
If you are using GCC, you can detect most errors before you even run your program by passing the "-Wall -Werror" options to GCC. That will tell GCC to report all warnings and treat them as errors. If you fix all the warnings, you will remove 90% of the errors in your code.
I also found a new trick yesterday. If you pass "-Os" to GCC, it will crank up the warning level as it will no longer auto-initialize stack variables for you. So you will see more errors where you failed to initialized a stack variable before use.
If you are using GCC and a debugger, don't forget to pass "-g" to GCC when compiling and
when linking. If you forget the latter, the debugging information will not be added to the executable during the link phase.