How to effectively do manual debugging? [closed]

Question

Say you don't have a debugger available, what would be an effective approach to debug code which doesn't work (as expected)?

Answer 1

There is a number of techniques:

1. Logging. If you've got no files access, log onto a serial console, or whatever output device is available. It is a good idea to always write your code with logging in mind, allowing a conditional compilation for different logging levels, from 'none' to 'overbloated'.

2. Cutting it down. Exclude the parts of your code around a suspected bug point one by one, and analyse what you've done when the bug disappears.

3. Assertions or contracts. It is a good idea to stuff your code with asserts from the very beginning. They not only help with debugging, but also serve as an additional documentation for your code.

4. Similar to 2. - vary your input and reshuffle the code unless the bug disappears or changes its behaviour. It is often a good idea to play with various optimisation levels (if you're coding in C or C++), as pointer-related bugs tend to be extremely volatile in their behaviour.

5. An automated version of 3. - use the instrumented code, e.g., run the binary under valgrind.

And of course there are many more tools and tricks, depending on the nature of your execution environment and your code.

Answer 2

Get a colleague and explain the problem in detail while you walk over the troublesome code step by step.

Frequently the act of explaining make it clear to either your colleague or yourself.

Answer 3

Is there a logging system to manage program output? Is there at least a console to print to or files you can write to? Using consoles or log files are a way you can debug without a debugger. Give the program an input such that you know what the output should be, then verify that the output works and make sure your logging gives you plenty of details of the process. Then try with an input that gives the wrong output. hopefully, the logs will give you a detailed trace of what went wrong.

Answer 4

Depends. Did it work before? If the code that used to work broke all of a sudden, then you should very carefully examine the most recent changes.

Answer 5

1) Do whatever you need to do to make the bug 100% reproducible, or as close to 100% as you can

2) Trace back the problem, using printf() or other logging facility. This is an art, though, and it depends on the nature of the bug.

If you have absolutely no idea about the location of the bug, but for example you know a condition becomes false at some point (the state of the program broke - let's call it isBroken()), you can do a drill down / partition search to figure out the location of the problem. For example, log the value of isBroken() at the beginning at end of major methods:

void doSomething (void)
{
    printf("START doSomething() : %d\n", isBroken());
    doFoo();
    doBar();
    printf("END doSomething() : %d\n", isBroken());
}

If in the log you see

START doSomething() : 0
END doSomething() : 1

you know something went wrong there. So you remove all the other logging code, and try this new version:

void doSomething (void)
{
    printf("START doSomething() : %d\n", isBroken());
    doFoo();
            printf("AFTER doFoo() : %d\n", isBroken());
    doBar();
    printf("END doSomething() : %d\n", isBroken());
}

Now in the log you may see this

START doSomething() : 0
AFTER doFoo() : 0
END doSomething() : 1

So now you know doBar() triggers the bug, and you can repeat the procedure above in doBar(). Ideally, you'll narrow down the error to a single line.

Of course this may help you reveal the symptoms of the bug and not the root cause - for example, you find a NULL pointer that shouldn't be NULL, but why? You can then log again, but checking for a different "broken" condition.

If you have a crash instead of a broken state, it's more or less the same - the last line of the log gives you a hint of where things break.

Answer 6

After the other answers have failed, there's always binary search debugging:

1. Eliminate a certain portion (preferably half) of the possible causes (lines of code, revisions, input, etc)
2. Try to reproduce the problem again.
3. If the problem persists: go back to step 1.
4. If you have only one cause (line of code, revision, piece of input, etc) left: hurray! Exit procedure.
5. Otherwise: revert step 1, and now eliminate the other half.
6. Go back to step 2.

Note: obviously, this technique only works if you can reliably reproduce the problem.

Answer 7

'"The most effective debugging tool is still careful thought, coupled with judiciously placed print statements." -- Brian Kernighan' In it's day it may have been true! The most effective method is to look at the unit tests but my guess is you do not have any.

Answer 8

It depends on the bug.

If the bug is the sort of 'why is the code doing A', then it can be useful to test your own understanding of the code surrounding the location of 'code doing A'. Introduce new code that you expect to generate new bugs (this code should make it do B, this should make it do C). I usually quickly find some new code that generates behavior that I don't expect. Then I wait patiently while my mind builds an updated mental model of the code behavior so that the last change makes sense, and then that mental model change usually explains why the code is doing A.

The second case has been discussed in detail here. Where you've either inherited the code, don't have a solid mental model of how the code works, don't have a good idea on the specific location of the bug, etc. In this case, drilldown/divide-and-conquer methods with print statements can work. And if it's under source control, make sure to check the most recent code change.

Answer 9

Expanding on the "The most effective debugging tool is still careful thought, coupled with judiciously placed print statements."

First, try to narrow down the moment the bug occurs. Make the user-observable symptoms system-observable. (say, some string changes to gibberish, add a loop that polls the content of the script and triggers your debug as it changes.) Of course if the error is a crash, add segfault handling.

Then try to narrow down the thread if the problem is with multi-threaded environment. Give each thread an identifier, and dump it when the bug occurs.

Once you have the thread, sprinkle the code of given thread with printfs copiously to nail down the point where it surfaces.

Then backtrace to where the actual action that creates it occurs (the destructive action will often be quite a bit before where the damaged data triggers the problem.) Examine what structures/variable occur nearby in the memory, observe loops that affect them, check points where the corrupted value is written to.

Once you have the point that was causing the problem, before fixing it, think twice what the correct behavior should be.