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'."
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.
Slightly off topic, but the apache project's log4j is the most elegent evolution of the "printk" school of debugging I have seen to date.
You can log against any backend source you feel like, flat files, syslog, databases, etc. You can remove the logging module entirely at runtime, without paying a performance hit for the debug statements. This saves a lot of jumping back and forth when you're trying to package up a release. If you're stuck without the fund$ for a top-end debugger it's the next best thing. It's for java, but I don't see any reason why the concept couldn't be ported to C++.
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
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. 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.
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.
/..sig file not found - permission denied.