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.
Here's what I was able to find on Google - freshmeat proved entirely useless (does anyone else think its search capabilities are somewhat, well, crappo? I'd like to see some better indexing on it.)
g t; that looks semi-mature, although the information on the webpage is sketchy at best.
b />SmartGDB</a>, which is described as a "scriptable, thread-aware" debugger.
I'd love to know, too, since gdb falls short on this.
The best I can offer is that the debugger that comes with Intel's free (for non-commerical use) compiler for linux probably works well, but I haven't installed it on my computer since I'm too lazy to install rpm on my machine and get it set up so that it won't scream when the installer runs rpm.
To that end, I was able to find a debugger called <A HREF=http://www.concerto.demon.co.uk/UPS/>UPS</a&
More useful may be <A HREF=http://hegel.ittc.ukans.edu/projects/smartgd
Hope that helps. . .
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.
And I quote (from the article), "I'd love to hear answers more substantive than 'use printf()' and/or 'just use ____, my favorite gdb frontend'".
/not/ fix any of the abovementioned problems with GDB. All it does is make the interface more manageable.
As we all know, DDD is just a frontend for GDB, and does
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!
Something that might be helpful, but not exactly what you are looking for is profiling and performance tools. Intel released their compiler and vtune (a performance analysis tool) recently for Linux:
:-(
http://www.intel.com/software/products/index.htm
I can't speak for the debugger, but when we switched our simulator from gcc to icc with profiling, we gained 25-30% performance. Needless to say, that was way cool. The other threading and vtune items might provide some useful insights to your code.
I hate to say it, but all the stuff I work on is generally so small, it's not worth the overhead to attach a debugger to it, so I'm not much of an expert in this area
- Mike
[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
He's not asking about what personal techniques you use, but about actual debuggers. He's also not interested in front ends to gdb that inherit the same problems of gdb, and I'm guessing the majority of your duh-go-check-freshmeat debuggers are front ends to gdb, which are just as worthless to the poster. oi.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Scroll up. More, all the way up. Read the article. Tkgdb is not what he wants. You may be able to figure out why.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
1.) valgrind (recently covered on slashdot)
2.) printf()
3.) gdb
4.) lint
5.) the proprietary debugger you mentioned.
6.) modify the thread library. (a niceties of open source/free software)
7.) modify your OS. (look into UML
Generally some combination of these should allow you to solve any programming problem on linux.
I find it amusing that a poster above calls everyone else illiterate for not reading the original post and then provides a link to a Transition System Analyzer for JAVA (the original poster is using C++)
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
Ever try using it to debug a program with more than two threads? Every try to figure out synchronization issues when printf has to serialize everything anyway? Printf has its places, but it's not a panacea. There are plenty of problems that cannot be debugged using it.
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.
What's gsb? I'd think it was a typo, but you mention it multiple times. Is gsb some other debugger derived from gdb that does what gdb doesn't? Or does what gdb does poorly, better?
:) I've no need for C/C++ debuggers personally, but I've seen ads for commercial Linux debuggers that advertise that they can deal with threads very well, probably because the free tools available don't do it well. I don't know the tools, but I've seen ads for them in DDJ and Linux Journal.
There are other debuggers for Linux, it's just that no one on Slashdot knows of them, as usual.
Aaron
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
It's probably the most useful response in this entire thread!
Brak: What's THAT?
Thundercleese: A light switch.. of TOTAL DEVASTATION!
Well, I haven't tried it, but what about Borland Kylix? The new version 3 claims to support ANSI/ISO C++ on Linux. And if you read the feature PDF on page 4 they mention many of the features you seek.
It might be worth taking a look.
First, the point: Etnus' Totalview is really good. It's also expensive if I remember correctly. It is almost the only good tool for debugging parallel (MPI or threaded) applications that I am aware of. More recently there is good C++ STL support available. (vectors, maps, sets, deques, etc.)
In fact, I have found it to work in many places gdb fails. (e.g. I can get a nonsensical stack trace in g++ compiled code under gdb that totalview can still make sense of.)
Apart from that, there are the memory checking tools that are incredibly useful, often far more so than a debugger since they tell you when something went wrong, not when the problem escalated into a full segfault. I wish purify were available for linux -- I hope valgrind is good, and hope to try it out soon, but haven't yet. There is also something called zerofault, but I doubt it is available for linux.
Sadly, your best course of action may be to run on other platforms (irix, win32, solaris) where there are different tools available more to your liking. I know that's a bit hard for some projects, but different platforms often make different bugs appear. (For example, some hardware/software IRIX combinations instantly bus error on null pointer dereferences, other IRIXes happily ignore them until they cause worse problems.)
Brian Kernighan and Rob Pike in The Practice of Programming say:
They go on to say that debuggers are valuable, and not to be overlooked. However they don't use them very much.
These are also well respected programers. I would recomend you follow their example unless you know a good reason not to.
P.S. typos in the above quote are my fault.
GVD is the GNU Visual Debugger, developed by ACT. It is entirily written in Ada using GTK+. It can debug programs generated with any of the GCC compilers in a variety of OSs. Check it out here
Linus and Alan Cox
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.