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'."
Ceci n'est pas un post
Hmmm, that's kinda like asking people how they drive and what's a good method. For every programmer, you're going to find somewhat differing technique.
Personally, I debug as I go, function by function, sometimes line-by-line. Others whip up a pile of code and then try to figure out what the hell's wrong with it _this_ time. Still others run it through a program to make some other programmer tell them what the hell's wrong _this_ time (debuggers.)
Search freshmeat using the word "bug" and see what comes up. Here's what I found:
Search on "bug" - 335 entries returned.
Search on "debug" - 199 entries returned.
Search on "debugger" - 78 entries returned.
Go for it, dude!
Everything in the Universe sucks: It's the law!
mmmm DDD is the bomb as far as I'm concerned. It's a front-end you can attach to multiple debuggers. Check it out, it's really nice.
download gdb source and compile it with tk support, it works great.
CowboyNeal and a magnifying glass.
Oh right, it's Ask Slashdot, not Polls.
I use assertions (in a crude "precondition/postcondition/invariant check" manner), and I haven't used a debugger in years (the occasional printf solves the rest).
So that isn't an answer, but it may be that developing a test suite (unit tests, plus assertions), may obviate the need for a debugger even on existing projects.
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
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.
Three good things about them:
1) They're portable
2) They can be piped to a file and post-processed with sed, grep, awk, etc. - basically, you can customize your debugging process
3) You _have_ to write good code, because print statements are only slightly better than staring at the code.
And if you're debugging multi-threaded code, why don't you sprinkle these all over the place:
if (rand() > RAND_MAX/2) sched_yield();
Can't help you with an alternative.
But.
What is your environment?? Distro. Source ??
Install from cd or internet?
Clean install?? Just programming?
Tried it with emacs??
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!
For IA32 and IA64 intel supplies C/C++ compilers and
debugger. Debugger is GDB compatible and could be used with DDD. You could get free unsupported versions though company has to buy at least one
legal copy in order to sell the product
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
Microsoft's Visual C++ debugger is excellent. You can visually debug multiple threads, watch variable values, even set breakpoints depending expression evaluated at runtime. You can even debug processes on remote machines.
oh, wait a minute.. Linux? then nevermind. Linus says debuggers are for wimps anyway, dontcha know?
cpeterso
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++)
What's wrong with printf????
Release the code and use your customers as the debuggers. You will quickly learn which parts of ya program are horribly broken.
Carefully package it up in a shiny box and see it and you local computer store.
Give it a cunning name such as Windows Me and wait...
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.)
If nothing does what you want, and your company does a whole heap of stuff in linux and _needs_ a better debugger - have you thought about sponsuring gdb development for what you need?...
Speaking of which... what exactly is it in gdb that needs fixing (thread stuff? what specifically??).. I use it fine with multithreaded apps all the time (a absolutely massive C program generally).
craz
stuff
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.
It's probably the most useful response in this entire thread!
Brak: What's THAT?
Thundercleese: A light switch.. of TOTAL DEVASTATION!
is your brain, use it.
I've spent long hours trying to debug programs when a little thinking could have solved the problem faster.
Also extensive timestamped logging gives a better picture about what the program does especially when multithreading.
A debugger is only important if there is a bug in the OS/linker/libraries - in this case re-thinkong your program won't solve too much.
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.)
Does anyone have info on Metrowerks' debugger? They have an IDE for Linux. It hasn't been rev'd recently AFAIK, and I haven't used it since beta. It has integration with GDB and kin, but the the current release also promises "Beta copy of Native X86 integrated debugger in Thrill Seeker directory". Any thrill seekers used it?
There are only one useable debugger - gdb. Which by it self is useless.
One needs one of the graphical frontends DDD or GVD (possibly kdbg).
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
IDA Pro Disassembler
It's not quite a debugger I suppose
Multiple Processor : same interface and features for dozens of processors
Fully Interactive : you work with the disassembler and forget about tedious multiple passes.
High Level Constructs, such as unions, structures, variable size structures and enumerated types.
Stack Variables keep track of your local variables, Local Variables.
Program Navigator Toolbar
Fully dynamic Global and Local Labels.
Low Level Constructs such as bitfields
Interactive Register Renaming makes RISC processors easy.
Auto-commenting : you can even define and use your own comments base.
Versatility : loads and disassemble virtually any file. Visit our gallery for a small subset.
Graphing : through a VCG Port. Graphing as it stands in version 4.21
thank God the internet isn't a human right.
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.
With the life sentences soon to be handed out to "hackers" who "endanger life" [it'll be interesting to see how far the lawyers stretch that], a good debuggerer could come in handy!
Ph33r m3!!!
From http://www.etnus.com/Products/TotalView/platforms/ index.html --
You can also use TotalView to debug programs that you have created using compilers provided by Lahey, KAI, and PGI. Gnu compilers are also supported. Your programs can be written in Fortran, C, C++, or assembler.
Parallel environments that TotalView supports include MPICH, OpenMP, PVM, and SHMEM.
Let me guess, you want something that will go through
your spaghetti code line by line with a cutesy GUI
and tell you not only where you screwed up but offer
suggestions for how to improve your code???
-
Are you writing this code from the ground up or are
you taking code written with visual c++ and attempting
to use it on a linux system??
Actually, GDB works quite well for multithreaded applications on MacOS X or other BSD MACH systems. It even is usable on Solaris, although Solaris threads are buggy in so many other ways ;^(
One of the big problems with GDB on Linux is LinuxThreads. Linux doesn't really have a notion of what a thread is. All threads in Linux are processes displayed in `ps'. When GDB sends a signal to stop a thread, all threads get a signal and immediately wake up from their semaphores, mutexes, or conditions and continue execution. Obviously, this crashes practically any MT application.
I've brought this to the attention of the LinuxThreads people a few times, but there isn't too much interest in fixing it.
For now I do all my development and debugging on MacOS X. Fortunately, everything usually runs OK when I move it over to Linux.
some versions of gdb will work with multiple threads, its just a matter of testing!
Also, for everyone saying "oh, just don't use a debugger" that might be practical for your applications, especially relatively small ones, but there are plenty of cases where nothing but a debugger is going to give you anough information to find the bug!