Nitemice

If you find yourself banging your head against a wall of code, stuck hunting for bugs or causes to erratic behaviour, it easy to get frustrated. And when you’re frustrated, it’s harder to think clearly about the best way to approach your problem. That’s why I’ve written myself a list of tips whenever I’ve been struck by the lightening of clarity and inspiration. And now I’m going to let you in on them.

Over the last ten months, working in my internship role as a junior programmer with support responsibilities, I’ve encountered (some would say, more than) my share of bugs, issues and little, niggly problems. As I have stumbled through this haze of confusion and perplexment, I have managed to collate a bit of a list of common and reoccurring steps and tips for troubleshooting my troubles.
They’re all pretty self-explanatory, and widely applicable to more than just my situation, so I’ve decided to let you in on them, in the hope that they can save someone else out there a few hours of turmoil.

I’ve grouped them into a few categories of similar ideas, so that you can find just the thing you need to get you out of a squeeze.

We can rebuild it

• Rebuild dependencies

• Do an "ascending rebuild"

This is something I’ve come up with where you start from your deepest working directory, and work your way out to the root of the project, rebuilding and testing at each level until it works. It might look something like: cd .. && make && runtests

• Recompile whole tree

To make sure you haven’t missed anything you need.

• Delete object files and rebuild

• Clean all built files and rebuild

Usually you have a script as part of your Make scripts that will clean up everything so you can try rebuilding from scratch.

• Delete files manually and rebuild

If you suspect there’s something going wrong in the clean-up, delete the files yourself to make sure they get rebuilt.

Test chamber ∞

• Rerun tests

• Run it on a different machine and/or OS

• Run it one more time, from scratch, throwing away any preconceptions

It may sound silly, but just letting go of what you expect to happen means that you can better assess what is actually happening, and maybe deduce the cause of your problems.

• Restart the server fresh, every time you run it

In certain situations, it’s better to start from scratch each time, to eliminate any extraneous causes. ONce you have things better under control, you can worry about what errors may occur from multiple runs, on a non-fresh setup.

Watch it work (or fail)

• Print whatever details you can

std out may seem rudimentary, but it can be your friend.

• Run it with breakpoints through Visual Studio/gdb

Both allow you set breakpoints by filename and line number, or by function name, as well as setting change monitors on variables. Also, if you’re not sure how a particular bit of code is being called, set a breakpoint for it, and then when it triggers, use the backtrace command in gdb to get a function/stack trace.

• Valgrind it

Often, Valgrind will reveal issues that you would have no idea existed otherwise, and if you include --leak-check=full and --show-reachable=yes it’ll lead you right to the problem areas.

Knowledge is power

• Google it

It’s obvious, but it’s still a good idea.

• Search the codebase

Maybe there’s something similar to what you’re trying to do somewhere else that you can use. Or maybe there’s a code comment that will give you a clue as to what you’re missing.

• Check any documentation

Be it for the tools you’re using, or internal documentation relating to the product you’re producing.

Check yo’self

• Check your repo is up to date

If you’re using git, that means running git fetch && git pull. If it’s SVN, it’s svn update.

• Check your branch & environment

Are you on the right branch, with the right environment variables set?

• Check ownership and permissions

Don’t just sudo it. If it won’t work, there’s probably a reason, and sudoing it may make it worse.

• Check your processes and do some "cleaning up"

Kill anything that shouldn’t be running, such as old instances of the program.

Understanding & piece of mind

• Reread the surrounding code and comments

Make sure you understand what it’s doing and what it was intended to do.

• Check code for any odd remnants that are unnecessary or interfering

Maybe you pasted more than you needed when you copied a chunk of code over. Maybe there’s something you said you’d get back to, and never did.

Things to ask yourself

• "Are you sure that’s what you think it is?"

• "Are you sure that does what you think it does?"

• "Are you sure that works the way you think it works?"

If you answered no to any of those questions, then you need to take some time to get to know your code a bit better.

Now, I’m no super-debugging expert, but these tips and reminders have save me a few times this year, so hopefully they can be useful to you too.
If you have any problems, feel free to send me a message, or leave a comment below!!

From your Friendly Neighbourhood

Nitemice