What Good Linux Debuggers Are There?

David Weekly asks: "I'm programming for a small software company that's got a fair bit of C++ code; we've been using gdb whilst on Linux, but have been a little frustrated by its shortcomings with multithreaded applications and its fumbling multiple inheritance issues. I poked around on the Net and, other than gdb, I was only able to find Etnus' TotalView as a modern, actively-developed Linux debugger. Are there really only two Linux debuggers (that one can take seriously)? How, for instance, do folks who code up Apache modules test them in multithreaded mode? (i.e., not just using '-X'.) I'd love to hear answers more substantive than 'use printf()' and/or 'just use ____, my favorite gdb frontend'."

Comments

Three bad things about them:

[Bastian]

1) You have to dive through the code to insert them and then recompile on every iteration of the debugging process.

2) You have to dive through the code to remove them and then recompile on every iteration of the debugging process if you don't want to keep getting info for finding bugs you've already fixed every time you run the program.

3) They clutter up your code and make it much less readable and maintainable.

and as a super extra bonus for everyone

4) The only workaround for problems (1) and (2) is fancy use of the preprocessor, which has the unwanted side effect of making (3) even worse!

Re:Multiple inheritance

[gkatsi]

This is not in any way a principle of OOP. That MI may not be appropriate in many cases where it is used is true. It is just as true, however, that it is absolutely essential in other cases. Just because Java has used interfaces as a poor substitute for MI, does not mean that MI is useless.

For more details, have a look at Andrei Alexandrescu's Modern C++ design. This book is an absolute eye-opener and it has done exactly that for a large part of the C++ community.

Asking the wrong question?

[jungd]

It seems that the choices for debuggers under Linux are a bit lacking.

I hate to remember how many hours I've spend using source debuggers - chasing down long call stacks, getting confused about just what was gong on.

Now however, I haven't used a debugger at all in the last 10 years, under either Windows or Linux. The difference? - Modern software engineering practice.

Although there are doubtless legitimate cases where a debugger is very useful; my opinion is that for any decient sized C++ codes, the application of a handful of coding techniques is a much better substitute.

If you're chasing memory problems, use a suitable (zero cost) templated smart pointer implementation - so you can't even compile code that would corrupt memory. Similarly, apropriate abstraction classes for synchonization can also provide all the logging information you'll need to chase down synchnonization issues in parallel codes - and will help avoiding many of them in the first place (research has come a long way since the days of using error-prone primitive semaphores in high-level code).

I suggest also liberal use of assertions (preconditions, postconditions, invariances) and multi-level logging.

In my experience, with these tools, bad code that would cause memory corruptions or synthronization deadlocks or race-conditions will just not compile. Any that aren't caught are usually easily seen with the logging output or assertions.

Hope my suggestions help - even though I didn't address your question. If you want to read more, pickup some books on modern generic programming in C++ and a couple software engineering texts.