What are your best debugging hints?

Question

What are the expert debugging hints for your favourite language, you think everyone should use?

As an example, I'll provide my C++ debugging hints, that between them help me shake out most of the bugs I come across, in this often hard-to-debug language.

C++

• Increase the warning level of your compiler to maximum, then stop those warnings which occur a lot and you've decided you don't care about (for me it's unused parameters). g++ doesn't warn about missing return statements in functions (a problem I find frequently) until the warning level is very high.

• Learn how to turn on your compiler's debugging standard library, and use it! ( -D_GLIBCXX_DEBUG for g++). This finds lots of errors, and also helps show exactly where the errors occurred.

• Always, always, always run your code through a really good memory checker, like valgrind, and fix all the problems it produces.

Answer 1

Learn what the different magic numbers means that VS memory handler writes when it handles memory.

0xCDCDCDCD Allocated in heap, but not initialized. By malloc
0xCCCCCCCC Allocated on stack, but not initialized.
0xDDDDDDDD Released heap memory. By free
0xFDFDFDFD "NoMansLand" fences automatically placed at boundary of heap memory. Should never be overwritten. If you do overwrite one, you're probably walking off the end of an array.
0xFEEEFEEE Deleted memory by HeapFree
0xBAADF00D Allocated in heap, but not initialized. By HeapAlloc
0xABABABAB Dont know. If someone know what this means, please add that.

Answer 2

A couple of my own, from spending too many nights debugging stuff that the compiler or runtime environment could have warned me about if I'd used it properly:

• If you're doing anything with pointers in C++, assert() them wherever suitable. In fact, assert()ing invariants is generally a good idea and can cut the debugging time on that one obscure bug from weeks to minutes. Just remember to turn them off in the release build. Oh, and don't put anything in there that has side effects, otherwise you'll be debugging your release build for a little while. Don't ask me how I found out that one
• In a similar vein, BOOST_STATIC_ASSERT can be extremely helpful in checking for discrepancies you can check at compile time
• Memory debuggers like PurifyPlus or valgrind are excellent time-saving devices and should be on every developer's machine
• Learn how to use the debugger properly so you can harness its full power instead of just using it as a device that allows you to single-step through your code
• If you're really stuck, explain the problem and the code to a colleague
• For C++, a tool like FlexeLint/PC-Lint can help pinpoint a lot of hard-to-find stuff once you configured it properly. You'll have to invest the time to configure it otherwise you'll drown in warnings
• If you're writing C++ and you're using the standard containers, write code that uses iterators and let the debug version of the runtime (or a debug STL) catch your off-by-one errors. If you use indices to reference elements in, say, a std::vector<> you'll have to find those yourself
• Run the code through different compilers if you can and pay heed to the warnings each one of them produces. However make sure that they're at similar levels of language compatibility (no point in running modern C++ code through MS VC++ 6) otherwise you'll end up chasing problems that aren't really there.

Ideally, you should try to catch problems before you need to fire up the debugger - anything you can tweak such that it creates a compilation error is much easier to fix compared to tracking it down in the debugger and then fixing it.