Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
Programming IT Technology

What Good Linux Debuggers Are There? 69

Posted by Cliff from the or...-working-around-the-gdb-shortcommings dept.
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'."
This discussion has been archived. No new comments can be posted.

What Good Linux Debuggers Are There? More

What Good Linux Debuggers Are There?

Comments Filter:
  • 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!

    • 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.)

      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&g t; that looks semi-mature, although the information on the webpage is sketchy at best.

      More useful may be <A HREF=http://hegel.ittc.ukans.edu/projects/smartgdb />SmartGDB</a>, which is described as a "scriptable, thread-aware" debugger.

      Hope that helps. . .
    • 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.
  • mmmm DDD [gnu.org] 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.
    • 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'".

      As we all know, DDD is just a frontend for GDB, and does /not/ fix any of the abovementioned problems with GDB. All it does is make the interface more manageable.

  • tkgdb (Score:1, Redundant)

    by norwoodites ( 226775 )
    download gdb source and compile it with tk support, it works great.
    • Scroll up. More, all the way up. Read the article. Tkgdb is not what he wants. You may be able to figure out why.
      • He needs a new gdb to fix some of his mutithread problems, os when he downloads gsb he gets one there too. Any way gdb is very good with threads, you can call any gdb function in a different thread.

        Also he needs to compile with gcc 3.1.1 to get better support of c++.

        Also I think there are no other debugger for linux because nobody wants to make one when gsb is there and it is the best one period.
        • 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?

          There are other debuggers for Linux, it's just that no one on Slashdot knows of them, as usual. :) 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.

          Aaron

  • You forgot a choice... (Score:1, Funny)

    by Anonymous Coward
    CowboyNeal and a magnifying glass.

    Oh right, it's Ask Slashdot, not Polls.

  • Multiple inheritance (Score:3, Flamebait)

    by gkatsi ( 39855 ) on Wednesday July 31, 2002 @07:03PM (#3989123)
    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.

  • My goodness, You are all illiterate! (Score:3, Interesting)

    by djm181 ( 585001 ) on Wednesday July 31, 2002 @07:21PM (#3989186)
    Is it just me or did the original poster say that they did not want to hear people say 'use printf' or 'use a gdb frontend'. And how many people replyed saying 'duh ... every tried using a print statement?'

    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 [ic.ac.uk] 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.

  • 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 [intel.com]

    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

  • Intel's Debugger (Score:5, Informative)

    by dew ( 3680 ) <david @ w eekly.org> on Wednesday July 31, 2002 @07:50PM (#3989280) Homepage Journal
    [article author] A number of people have thoughtfully suggested trying out Intel's debugger (aka LDB). Unfortunately, from what I found [ualberta.ca], 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.
  • 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?

  • Choices (Score:2, Informative)

    by digitaltraveller ( 167469 )
    1.) valgrind [kde.org](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 [user-mode-linux.org]

    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 (Score:3, Informative)

    by dirtydamo ( 160364 ) on Wednesday July 31, 2002 @09:49PM (#3989764)
    UPS [demon.co.uk] 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

  • Sorry, No Good Linux Debuggers (Score:4, Interesting)

    by vharron ( 106972 ) on Wednesday July 31, 2002 @09:55PM (#3989792)
    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

    • Yeah, given the itch scratching nature of open source I'm stumped by the shortage of Linux debuggers and how little they've progressed since I graduated from college four years ago. I would have honestly expected Linux to have the cream-of-the-crop of debugging tools by now.

      In addition to VC++/.NET don't forgot the seriously powerful lower-level debuggers like windbg, cdb, and the NT kernel debugger [microsoft.com] (all free). I couldn't imagine developing a serious app without these kinds of tools.

    • You may want to take a look at Borland's Kylix [borland.com], the linux-native port of Borland's respocted IDE's for C, C++, and Delphi (they claim it supports the same features as windows versions). It comes with a high quality debugger/profiler, and, while not free, a trial version is available.

  • Asking the wrong question? (Score:3, Insightful)

    by jungd ( 223367 ) on Wednesday July 31, 2002 @11:36PM (#3990127)

    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.

    • It's probably the most useful response in this entire thread!

    • I had a witty response all planned, but let me just be blunt: Are you a masochist? Either that or you're not doing serious C++ development, or you're a manager that doesn't write code.

      My team uses everything you mention, with the addition of some other stuff like automatic memory leak detection and OS-level hooks to detect heap corruption, invalid handle usage, etc. [microsoft.com] I'm not even sure how your smart pointer template library would detect or prevent all heap corruption bugs, as they aren't always caused by dangling pointers...

      While these techniques and tools are great, even with great programming practices there's no way you can eliminate all bugs this way. People make mistakes.

      So when you're in the initial stages of development you're meaning to tell me that neither you nor anybody on your team makes a mistake where you end up dereferencing a NULL pointer? Or do you try to track it down from the logging instead of taking three seconds to get a call stack with symbols and line number information in a debugger? What about when another component or library crashes or returns an unexpected result; don't you investigate? What about subtle logic flaws that become readily apparent when stepping through the code with a debugger? You can't log everything.

      • Any code that dereferences a null pointer cannot be using good quality smart pointers. I am a little skeptical about working ten years w/o a debugger but I have seen the importance of the debugger shrink dramatically as I adopt modern C++ design practices. In the past two or three years virtually every bug that has forced me to use a debugger was caused by old C code or C++ code inherited from C programmers. Correct use of smart pointers and const declarations would have prevented 90% of those bugs.
      • Either that or you're not doing serious C++ development, or you're a manager that doesn't write code.

        Yes, I've been doing serious C++ programming for years (of varying degrees of seriousness :). I am not a manager.

        My team uses everything you mention, with the addition of some other stuff like automatic memory leak detection and OS-level hooks to detectI...

        You won't need automatic memory leak detection if you make it *impossible* to program.

        While these techniques and tools are great, even with great programming practices there's no way you can eliminate all bugs this way. People make mistakes.

        Yes, people make mistakes - that is what the compiler is for (for the most part - of course I'm not claiming it can get *everything*)

        So when you're in the initial stages of development you're meaning to tell me that neither you nor anybody on your team makes a mistake where you end up dereferencing a NULL pointer?

        Correct. The smart-ptr class we use doesn't allow any such thing. Why on earth would you want to allow the concept of pointing to nothing? - it doesn't even make sense. Change your smart-ptr class to not allow initialization or assigmnent from anything but another smart-ptr. The constructor can construct new instances too, so it is impossible to have a pointer point to anything but a valid object. Our smart-ptr also checks the validity of the address with our memory management system before any dereference too - just in case it gets corrupted via some other mechanism - but that is very very rare.

        What about when another component or library crashes or returns an unexpected result; don't you investigate? What about subtle logic flaws that become readily apparent when stepping through the code with a debugger? You can't log everything.

        I admit we typically either have developed all the code in the system (save OS calls), or have control over the source of other libraries - so we can apply the same techniques to them. Not everyone can have that control.

        Check out Andrei Alexandrescu's book on modern C++ design for a half-decient smart-ptr class to use as a starting point.

        • Memory leaks are *not* generally statically detectable. That is, you cannot detect them at compile time.

          The only way you can statically detect memory leaks is by severely restricting the kinds of data structures that you are allowed to create; i.e., by throwing away a huge amount of solution space.

          What kind of tradeoff is that?

          • Memory leaks are *not* generally statically detectable. That is, you cannot detect them at compile time.

            But you *can* make it impossible to write code that leaks - at compile time.

            Your compiler can enforce correct use of a smart-ptr - one which also manages storage either by reporting memory that was not manually reclaimed, or just automatically reclaiming it (garbage collection) - or both. If you use a garbage collector (either to reclaim all storage or just to get what you missed) then your code will not leak unless there is a bug in the collector or smart-ptr code.

            There are also garbage collection techniques for C++ that work fine with C pointers and malloc/free - although I don't use them. They typically don't provide all the other type safety benefits of the smart-ptr approach.

            • PS: You are right though - that if you don't use a garbage collector, if a smart-ptr is just reporting leaks - they are still leaks. That is why I use a garbage collector.

              • Now that you bring up garbage collection, I believe you are on the right track.

                However, my original point is that it is highly misleading to claim that using a static language construct can prevent memory leaks. What you seem to have meant is that language constructs can allow you to *detect* leaks at runtime, or that runtime support can allow garbage collection.

                Your original post made it sound like "if the compiler doesn't complain, the code doesn't leak." Which is simply not possible, except under exceedingly restrictive conditions on the data structures the language supports.

        • Re:Asking the wrong question? (Score:1, Informative)

          by Anonymous Coward
          Andrei's chapter on smart pointers is available here:
          http://www.moderncppdesign.com/
          but you have to give an e-mail address to read it.
        • So is there any chance of you making your smart pointer class available? I'd certainly be interested in seeing it.

  • Well, I haven't tried it, but what about Borland Kylix [borland.com]? The new version 3 claims to support ANSI/ISO C++ on Linux. And if you read the feature PDF [borland.com] 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 [metrowerks.com]. 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?

  • Brian Kernighan and Rob Pike in The Practice of Programming say:

    As a personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we tind stepping through a program less productice than thinking harder and adding output statements and self-checking code at critical plays. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where tht is. More important, debugging statments stay with the program; debugger sessions are transient.

    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.

  • Try GVD (Score:2, Informative)

    by Smooth Hound ( 594058 )
    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 [act-europe.fr]
  • IDA Pro Disassembler [datarescue.com]

    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
  • Linus and Alan Cox

  • 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!

  • We like TotalView a lot [we haven't tried it on a Linux cluster yet].

    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.

  • 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.

Slashdot Top Deals

The bigger the theory the better.

Close