Slashdot Mirror
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'."
I have not worked much with threaded applications, but I have encountered the problems with multiple inheritance.
What I've ended up doing in hard cases (where printf will not help) is create local pointers to the parent classes and examine them from gdb. Once the problem is solved, the extra variables are gone, too.
Example:
Base1 *b1 = dynamic_cast[Base1*](this);
Base2 *b2 = dynamic_cast[Base2*](this);
(change [] to less-than and greater-than).
Of course, this will not help when your hierarchy is more than a couple of levels deep and things get even more complicated when the parent class is actually a template argument.
I hope, however, that this is just a very-hard-to-fix bug in gdb, as opposed to an even deeper design problem (as I think is the case with threaded code). So there might still be hope.
Please read an entire post before replying.
Finally, what do I use for multithreaded application debugging? I don't have a tool for once I've cut the code but if you define your system using Finite State Processes then you can use the LTS Analyser to check for deadlocks etc and you can step through a concurrent system generating whatever event you like. It is worth a look, although matching your code to your model is still tricky. And of course you need to learn FSP, but the website above teaches you.
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!
[article author] A number of people have thoughtfully suggested trying out Intel's debugger (aka LDB). Unfortunately, from what I found, it looks like LDB has only a subset of gdb functions, and can't even do simple things, like attach to processes. It seems that Intel has given up making their own Linux debugger and has decided to join up with GDB development. That's why I didn't include it. Thanks anyhow to those who did suggest it and thanks to those of you who suggested some other debuggers; I'll take a look at them.
David E. Weekly
Code / Think / Teach / Learn
h4x0r for
UPS is the only debugger I use anymore! I've never used it in the situations you asked about (multithreaded code etc), but I have generally found it's a very fast and lean debugger. It's also cross-platform, which is nice.
(The only real downside is its user interface, which isn't too great.)
It's really quite depressing. From what I can tell, no one makes a quality debugger for Linux. I would pay serious cash for the equivalent of Visual C++ on Linux, but no such product exists. All recent versions of gdb drop core on me every time when trying to attach to a process -- and it's the best debugger available. I'm not doing anything fancy, just some shared libraries and occasionally some threads. Low quality tools are probably costing the Linux community more than anyone can estimate.
We develop software for Linux and PS2 but all of our code builds on Windows and we spend most of our time working there. I strongly recommend you use a Windows XP/2000 and Visual C++ as your main development environment and port to Linux periodically. You'll save yourself countless hours of misery.
Good luck,
Vince Harron
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.
/..sig file not found - permission denied.