“As important as debugging is, especially in game development, techniques in debugging are rarely taught.” – Mike McShaffry
Luckily, Norman Matloff wrote a nice article about how to properly debug software and find even the nastiest bugs using the gdb. The introduction of the text applies to all programming environments and might be helpful for everyone, so here’s a short summary.
Matloff understands the process of hunting a bug as follows:
“Finding your bug is a process of confirming the many things you believe are true, until you find one which is not true.”
An example might be that you assume a certain variable value at some point of execution. Then, the task of finding the bug boils down to the verification of this variable value. Matloff proposes some kind of binary search strategy: For the sake of simplicity, we assume our program is composed of 100 lines of code without any jumps or function calls. Then, check the value of the variable at line 50 – if it isn’t correct, you just narrowed down your search space to lines 1-49. Next, check the value at line 25, and so on.
This easily extends to most programs which contain jumps and function calls, of course. In the case of a game, you just need to fully understand the nature of your game loop, that is, the order of update and draw calls and the order your game components are ticked.
Things get a little hairy for distributed or multi-threaded applications… If you don’t have a proper debugger at hand, you’ll have to use log output in order to ensure that all variable values are properly sent and received between machines and/or threads, and that all function calls are properly passed along with their parameter values.
Take a look at the original article and let me close with a quote by one of my supervisors at Kiel University that’s been on my mind for years now: “If the bug can’t be found where you expect it to be, you’d better start looking where you don’t.”