What are your favorite debugging techniques in C++? [closed]

Answer 1

Let's not forget valgrind ... it's saved my bacon on more than one occasion by helping find that obscure once-in-100-runs memory corruption or uninitialized-value error.

Answer 2

Reactive measures:

• Using a good debugger, especially of the integrated variety. Use a debugger that works visually with your code.

• Debugging tactics. Familiarity with your tools. Knowledge of common pitfalls. The process of deduction. Using hypothesis and branching on different ideas.. returning to previous ideas when needed. Tracking your debugging progress. The scientific method.

• Analytical tools (e.g. Dependancy Walker, .NET Reflector), memory dumps, stack traces and logs.

Preventative measures:

• Small incremental builds. During active development, add to your project piece-by-piece and test each incoming piece. Don't spew out a bunch of code and then mash Run and blithely correct each error. Add to your program piece by piece and take the time to fix everything. Try to make each increment in your project 'atomic'.

• Multi-level logging, as others have already pointed out. Have a severity scale running from trace up to fatal error and everything in between. Your production app should log every single thing that it does and why it succeeded or failed, but you should also be able to alter the logging level when an extreme level of detail is not needed. Logs should be human readable as a first priority.

• Fail-safe logging. Don't depend on your logging mechanism to survive exceptional situations. Always have a back up plan - the event log, a flat text file, a last ditch email - for when things go bottoms up.

• Good source control policy. Frequent check-ins on a regular schedule at minimum, plus check-ins for any and all groups of changes, particularly widespread or possibly breaking changes.

Answer 3

Multi-level logging systems. I find use for at least 5 levels:

• verbose: stuff you only want to see when debugging low-level stuff like protocol errors; may be compiled out of release binaries, so you can put stuff in this level that you don't want your end users to find

• internal: lower-level tracing than normal level, which is frequently useful, but not so often that you want to see it all the time

• normal: default output level, for stuff useful to anyone watching the system run normally

• problem: run-time errors that the program knows how to cope with; you might choose to run at this level for release versions, instead of normal

• fatal error: "scream and die" type messages, like out-of-memory

Multi-level logging lets you build plenty of logging info into the program without having to see it all the time. You turn up the log level only when you have to debug something, then put it back to its normal level. When doing "printf" type debugging -- temporary messages -- I put them in at normal level, so I don't have to crank up the log level to see them, and have them be obscured by the noisy internal or verbose level messages.

Answer 4

I vote for gdb. Especially when all you have to work with is a core file.

printf's are nice when you have a general idea where the bug is. But when the test team comes back to you w/ a core file and a weird description of the problem, to be able to analyze the core dump will give you a tremendous head start in your debugging effort.

Answer 5

For this one, I'm going to have to go with deliberately structuring the project to minimize incremental build/iteration times. As a side effect, these are the same steps it takes to keep edit-and-continue working properly.

Answer 6

IMO one of the most powerful ways of debugging server code is Differential Debugging, that is comparing two log files.

It is especially useful with legacy code when the current developers don't know all areas of the code. It helps narrow the search area and the code that has to be analysed. It does require good logging/tracing to be present already.

This works when you have a use case that succeeds and one that fails. For example feature X used to work in version 3 of your product but now is broken in version 4, and no one knows why.

Compare the logs, use awk or sed to strip out the redundant differences (these scripts can be reused):

• Time stamps
• Thread IDs - sometimes filter on a particular thread
• paths
• etc

When you see the logs diverge, this usually indicates a wrong decisions was made just before.

I used this technique to replace a proprietary middleware solution in a legacy system with CORBA and ensure that I did not change the behaviour of the application logic. But it is very useful in lots of situations.