Slashdot Mirror
How Would You Improve Today's Debugging Tools?
redelvis asks: "I recently came across an article by MIT's Media Lab on 'The Debugging Scandal and What to Do About It'. It's a few years old now, but it really got me thinking about how little the debugging process has improved over the last 5,10 or even 30 years. I have developed applications using modern IDE debuggers such as Borland's JBuilder, Microsoft's Visual C++, as well as standard tools like gdb and jdb. Despite the slick graphical interfaces, nice thread stack traces and local variable browsers, I still make sure I have on hand plenty of notepads, graph paper, pens and pencils so I can try to build up a picture of what state the program is in and to help me play detective in pinpointing what is going wrong with my (or other peoples) programs. Do other developers have similar problems? Do they find modern IDEs and debuggers have shortcomings in helping track down bugs? What would make a better debugger? Why do you think so much effort been invested in areas such as advanced modelling tools but so little in improving debugging tools?"
One of my biggest problems with people on my current project is the lack of knowledge of how to use even the most basic tools. We program in C++ on Unix and many developers find calling up dbx to be a chore and, even when they get dbx up, have trouble using it. We have many other tools, ddd, other graphical debuggers but people just don't use them, relying on printfs and couts...
main(i){(10-putchar(((25208>>3*(i+=3))&7)+(i ?i-4?100:65:10)))?main(i-4):i;}
I'm a total amateur, but I personally find that software tools can ultimately only go so far in debugging. The two most important debugging tools I'm aware of can't be solved with software: a short break from the project to clear your train of thought, and another set of eyes which might better see what you've overlooked.
----------
Something cleverddd's visualization capabilities are terrific. You might be able to get rid of the graph paper.
The real problem is that the majority of software that is written is fairly lousy. People often code to moving requirements, push code in directions it was never intended to go in, and work with designs that are in desperate need of landing on the compost heap.
Honest debugging is most useful when something is being developed in the first place. Domain knowledge is what is most useful when ancient and decrepit software is being modified to do something it shouldn't.
Software applications should be thought of as prarie lands. From time to time, lightning strikes, and burns out a huge chunk, which is all replaced by newer and healthier stuff. You need talented people to make sure the new code will work well with what's already there - but the end result is that the application will be healthier if frequent refactoring is done intelligently.
Education is the silver bullet.
Debugging is difficult primarily because debuggers do not appear to use any kind of intuition.
Let's say I have a break point on an if statement. The debugger should automatically show me the values of any variables in the condition, as well as the truth values of the individual expressions in that condition.
A debugger should have an "intelligent" step button that steps into code that has debugging symbols, but steps over system calls. It should also automatically skip to the end of loops if desired.
Debuggers should have "sanity" checks for values. Any time a pointer is null, or an long integer is set to some really wild value (like -3492883773642) that is nowhere close to the values that it originally contained, or a string doesn't have a null terminator, the debugger should alert you with a little icon, even if you aren't actively watching that variable.
One thing that sucks about debugging is when programs behave differently in the debugging environment than they do once compiled. We had several problems related to event handling in Visual Basic only occured if the program had been compiled. In debug mode, it worked fine.
Debuggers should keep a "state" history, especially for loops or recursive functions, so you can see the entire progression of a set of variables until the point of failure. This eliminates having to write in a bunch of printf statements to get a snapshot of each loop iteration or function call.
The debugger should be integrated into the IDE so you don't have to switch back and forth. Also, it would be really nice if debuggers executed under some kind of virtual machine that allowed you to more easily freeze execution, rewind it, tinker with it as it's running, etc. Visual Basic allows you to do some of this, but certain code changes require you to restart the whole program. I'd like it if you never had to restart, and the line between "debug mode" and "design mode" were almost entirely blurred.
Just my $0.02.
bytesmythe
Hypocrisy is the resin that holds the plywood of society together.
-- Scott Meyer
Sure, we all like debuggers with conditional breakpoints and backward stepping, but the more you add to the debugger the less opportunity you will of finding the bug (unless its a 'smack in the face' bug).
The only way of truely solving bugs is to know exactly whats going on in the code (and, also as important, is knowing the language, operating system, and the things going on in the background. IE - in Java, although it appears as if you aren't dealing with pointers, you are, and you should treat all objects like a reference, cause that's what they are). If you can't study the code (cause it was written poorly), it is a terrible terrible thing, because most bugs are not just one line fixes (and even those that are require you to know exactly what all is going on around them).
"Cherry picking" (just tuning up one line and "guessing" that that's the problem) is what most 'amateurs that taught themselves coding' do, and on major/enourmously large projects, this will do nothing more than cause trouble.
The best way to beat a bug is knowledge.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Let's not confuse testing with debugging. Debugging occurs when a program does not function as planned, whether an error is thrown or a bug is found by a testor or client. In a ideal situation all bugs are located and corrected during the testing cycle of the development process. However, testing is an expensive and time consuming process and a great number of companies settle for finding the big and obvious problems.
Meddle thou not in the affairs of Dragons, for thou art crunchy and with most anything.
"Since my favorite language is VB ( watch the flames poor in on that statement )..."
I don't really understand Slashdot's attitude about VB. I don't consider myself a programmer, but I've been able to use it to automate some stuff in Windows. I think it's great, especially when it comes to creating GUIs.
Every language has its strengths. Making of of VB because it doesn't do something another language does is like making fun of cars because they can't fly. Nobody's going to use a 747 to take a trip to 7-11.
I use debuggers every day, and find them indespensible for tracking down obscure bugs. (Like the one I just hit a few minutes ago - why does MSVC barf when calling vector::clear? The debugger stops app execution in _free_base() in free.c. This doesn't happen if I recompile using STLPort instead of the default stl library. ) That said, when I don't use a debugger I'm sure I find myself writing more robust code - I'm more inclined to spend more time on proper exception handling, thinking about my design instead of: write, compile, run, oh it failed on line 2493, fix that line, run again, now it fails at line 2547, fix that ....
which results in code that works under the exact set of circumstances that you test it, but has no guarantee as to what will happen if the parameters change any. (And those pesky users always find those annoying 'special cases').
the best way to build a skyscraper is not to use CAD programs at all, but a slide rule and pen'n'paper, which force you to think about what you're doing instead of making mistakes and 'correcting them later'.
;)
come on! You can't tell me that to be a Real Programmer one has to forgo color syntax highlighting, automatic indentation, automatic code formatting, automatic brace insertion, etags, man-on-symbol-at-point, folding, autodoc of functions, gcc -Wall -Weverything-but-the-kitchen-sink etc. etc. etc.
Personally I believe that being able to isolate myself to having to indent manually the next line and similar stuff makes me a better programmer, as I'm able to think about structure & what I want the function to be doing vs why the %##*%^ editor doesn't do what I want.
I'd also like to see you 'not put the bugs in in the first place' if you're adding a complex piece of functionality to a 2,000,000 lines program: I can write perfect 'hello world' code on a napkin, but considering doing it for real work is ludicrous.
Debugging is also an art, and I don't think I've ever found a bug I wasn't able to trace via judicious use of the tools currently available on the market right now, which are (from less to most esoteric):
- compile with as many warnings on as you can
- reading the docs/code comments (some bugs are really features
- the mighty printf/cout/cerr
- find/grep
- vanilla breakpoints in your debugger of choice
- tcpdump/openssl s_client/telnet/other packet monitoring stuff
- purify/ad-hoc malloc library
- hardware watchpoints in gdb (saved me a few times)
- sleeping on it/going for a walk (let your subconscious do its thing)
Only thing I'd like that current debuggers on unix don't have is what you can do in windows by inserting a certain line in your code that when is reached it automagically halts and pops up the debugger: when debugging multithreaded/multiprocess stuff that has bugs only when not running singleprocess/singlethread it's invaluable: anybody knows how to do that in unix?
-- the cake is a lie
Since my favorite language is VB
Personally, I think of VB as a scripting interface for Windows GUI work rather than an actual programming language, but that is also its strength. There is no perfect programming language - they all have their pros and cons, and while VB is slow compared to C++ for calculations, VB is extremely handy for operating a GUI - an area where C++ is tricker.
One shouldn't try to drive a screw with a hammer just because the hammer is more 'elite' - use the right tool for the job.
That's one I've actually wanted before. I'd like to see something where you could specify a list of "Watch" variables, and snapshot points. then let the program run. It takes snaps of all variables at each point. you can then go back and review what happened. Get a nice grid of variable values by point in time.
It's a lot faster then setting watches and breakpoints and having to write or remember what happened at each point.
There is nothing so silly as other peoples traditions, and nothing so sacred as our own.
Ah, but here's the problem. People fail to understand the purpose of VB far too often.
/images/yyyy/mm/dd/hh_mm_ss.jpg then it's a wonderful thing. Add a webcam component, then another for jpg (VB can only save BMP), and in a few minutes it will be done.
VB is great for writing small apps. If say, you want to write a program that takes photos at an interval and automatically saves them in
Now, the problem begins when this little program grows. If you try to write big apps with VB you'll fairly soon start hitting its limitations, writing workarounds, having to put up with completely idiotic bugs like project files that break by themselves... and you end with a complete piece of crap.
Also, pretty much anything that can be done with VB can be done in Linux with Perl and PerlQt, perhaps with some help from other apps. Pretty much the only thing I couldn't find a replacement for is such a great debugger.
As a Web developer, time is on the line and almost everything I do is in a rapid development environment. That being said, debugging information is extremely important.
On the ASP.NET and Cold Fusion MX application servers, the debugging information provided by each is excellent and thorough. On CFMX, each error is specified by line on the template on which it occurs and provides a 'stack trace' (meaning a list of all the pages involved in generating that particular Web page), execution times for each template, and a complete list of all variables in all scopes. Complex variables, such as structures and arrays, are output along with all the rest in an easy-to-understand format.
The one thing that could be done better by every application system, IMHO, is a self-documetation feature. I would like to be able to look at the source code and see a breakdown of all variables on the page right away. This may sound a little simple and not really a debugging tool, but I look at it as preventive maintenence.
ddd is, by far, the best debugger I've ever used. I used to hate visual debuggers, but ddd turned me around.
That being said, however, there is one improvement I'd like to see in all debuggers. That's a way to do memory checking. In other words, integrate Purify or Insure++ functionality into the debugger and have it break anytime there is a memory stomp. Memory problems are the biggest issue facing programmers of large, complex systems.
For those of you who say to write small objects and give them unit tests, or to rely on things like printf(), I suggest that you get a job in the real world. Complex systems are written by large groups of people. When you hit a problem, it may or may not be in your own code. It may or may not be because you're using an object incorrectly. You need a debugger to figure out where things are blowing up and why. Using printf() will work, but it's slow and requires multiple compile/link/test cycles. Not the best use of your time.
"Much of the server-side world doesn't use traditional debugging tools at all- they use small, well defined functions/methods, which are easy to unit test."
Well, when you combine enough of your small functions/methods together into one big monolith of a program problems tend to surface. What then?
Even when using some fully tested COTS library to solve all of your problems the programmer WILL run into integration issues due to unintended use or misunderstanding.
"I've seen as developers gain experience, they rely less and less on interactive debuggers, and more on automated testing and configurable logging."
I have been coding for over two decades and have yet to see a reason to abandon debugger use. It is essential, like an x-ray / CT-scan / ultrasound is to a surgeon. Black box and even white box testing will only tell you so much. Sometimes you need to see the cogs in motion.
come on fhqwhgads
Doesn't work very well with recursive functions. Especially recursive functions that call other recursive functions. Ever tried to write a recursive descent parser? Next to impossible without a good debugger. You need to be able to step through the code line by line and watch variables as they are loaded on to(and popped off) the stack. No way are print statements going to be nearly as helpful.
No, Thursday's out. How about never - is never good for you?
Testing is to identify if there is a problem, and hopefully under what conditions they will occur. Debugging is to identify the cause of that problem, and what needs to be done to fix it. One is most definatly not a replacement for the other.
Now, the problem begins when this little program grows. If you try to write big apps with VB you'll fairly soon start hitting its limitations, writing workarounds, having to put up with completely idiotic bugs like project files that break by themselves... and you end with a complete piece of crap.
.NET languages seem to be minor syntax variations on Java, maybe that's not too surprising.)
Amen. If people knew that whenever they needed write a program longer than a page that they should switch away from VB, I'd have no complaints with it. Instead, it is marketed in such a way that it gives amateurs the notion that they're just as good as any professional programmer. It's as if people thought that buying a Tinkertoy kit made them able to build houses.
I don't know how many projects I've seen where someone has knocked together a prototype in some half-baked language like VB. Then people want another feature and another, and nobody is willing to say: "Stop! We must throw this crap out and start again using appropriate tools."
(For the record, I hear that VB.NET is a big improvement over the execrable VB6. Of course, given that all
Agreed. Since changing from C to Java several years ago I find that I never use debuggers anymore, relying instead on verbose logging to understand what my program is doing. I think in C debuggers help more because you can abuse memory in various ways that you don't need to worry about so much in Java. With a debugger it is really easy to see yourself walk off the end of an array, for example. I also observe that my peers who rely strictly on debuggers don't tend to do much logging. So when their software is in production they are mystified when it acts up. I also notice that they don't comment as verbosely either but I can't prove that's because they use a debugger. Maybe they wouldn't comment anyway.
"Interpreted" is not the same as "dynamic". You can have both speed and a productive environment.
Programming can be fun again. Film at 11.
is for a debugger that can do a good job in simulating multithreaded operation. If a debugger could:
1. Break all threads in one or more processes
2. Simulate timeslice execution of all threads as the user steps through
That would be very good. Many of you probably noticed that debuggers don't do a very good job of this, and sometimes threads can either behave too well or too poorly.
Another nice feature would be the ability to have complete control over what threads to starve and what threads to execute. This would make testing of critical section code much easier by giving us the ability to simulate worst case scenarios in matters of concurrency.
Finally, I'd like to have more extensible debuggers so I can create my own variable watch plugins that depict things more graphically than a simple watch list.
Wow, you really hate VB. Before I answer your post, let me say that I hate VB's syntax, the fact that it's not truly object oriented, and the weird, back-asswards way it does things. So I'm not totally against you on this. I'd rather be working in C++ or even C, so take the following in context, ok?
VB *CAN* be used for relatively larger projects, BUT, it depends on what kind of programmer is involved. I've inherited some semi-large VB projects, including a three-tier client-server setup built from VB programs, MTS dlls, ASP pages, and a pretty big database, with a lot of lines of code (not just a page). Luckily for me, the original programmer had an engineering background, so his code was pretty tight and the project was in pretty good shape. I made beaucoup changes to it, updating it to account for a number of policy changes. I had to totally redesign chunks of it because of changes in the way a number of pieces of data were going to be handled in the future, etc, and of course I had a great deal of bug-hunting to do. But, overall, despite the fact that this was a big, complex project, it all went pretty well. We're now moving into a phase where the system's going to be expanded again, to add features. It's growing, in other words -- bigger and bigger. And, it's not giving us that much trouble in the process.
I think where large projects run into trouble with VB is when they are run by people who do NOT have a solid computer science background. All too often, a secretary or clerk is sent off to a VB class, baptized as a programmer, and handed a copy of VB, Professional Edition. Then this clueless person is expected to be able to handle a large project. No knowledge of data or file structures, no knowledge of relational database design or algorithms, but they're given the tools and admin access to a test database, plus a big project. Naturally, the person A) shits his pants and runs to Border's to buy a VB picture-cook-book with lots of yummy recipes in it, B) makes a good faith effort and totally fucks it up, and C) doesn't know what the hell hit him when the project implodes the day before the deadline (or am I being too harsh here?).
But don't blame VB for it; blame the manager who's too stupid to know that computer programming is an engineering task requiring more than a six-week VB course to learn how to do properly. I feel sorry for the poor noob who gets flattered into thinking he's a programmer; he's the one that takes it in the shorts, generally.
Sorry for the elitist rant, but...
Farewell! It's been a fine buncha years!
A big part of the reason is that the languages paradigms that are popular today are directly copied from what was popular 5, 10, or even 30 years ago, with a little bit of a half-baked object system thrown on top (think C++, Java, etc.). Statically compiled "structured" programs don't lend themselves well to debugging, period. First of all, the debugger has to do a lot of contortion to do relatively simple stuff like stack and variable inspection. Then comes the problem of the "structured" style itself, which depends heavily on variable assignment and is very un-modular.
OO-design does reduce the granularity of program modularization and lessens the dependence on global variables somewhat, but inside, the objects are still programmed in a "structured" way. Even worse, object-overuse leads to a rat's nest of an object graph (my big beef with single-inheritance only object systems is that they encourage this).
For debuggers, steppers and stack-tracing to be really effective, a program has to be modularized with as fine granularity as possible. This is why functional and pseudo-functional languages generally tend to have and develop the best debuggers. Even before implementing any features, an interactive top-level is probably the best debugging tool available. But implementing stuff like advanced condition handling/breakpoints, stack-tracing/variable inspection, and function-tracing/steppers fits naturally into the language environment with minimal detriments to code size (anyone up for a little Java catch?) and performance.
In the great CONS chain of life, you can either be the CAR or be in the CDR.
That's is exactly why good developers prefer verbose logging instead of debugging.
If verbose logging is applied in a smart way, errors will show up in such a way you will be able to see where and why the code fails. Then it's up to the developer to find out if either te predicates are wrong or the context to which they apply fails... (emphasis added)
That's ridiculous! I'd say that good developers use both. And they also use assertions.
Logging gives you a picture of your program over time. It's a great tool and can help find bugs that are otherwise difficult. You can watch states change, and see method calls, from your hand picked logging statements.
On the other hand a debugger gives you an instant snapshot of your program, and allows you to inspect the state in detail. Again, another great tool.
Logging's greatest weakness is it requires an edit-compile cycle to get new messages in. And it's real easy to end up not having messages in the right spots or not displaying enough information (or the right information).
Whereas with a debugger you can load the program up, set a break point, run, and then step through and see what's happening. No edit, no compile, you're just there. But it's greatest weakness is watching the program state change over a long time.
So they're both great tools and are good for different things. Good programmers know how to use the tools that are available to them.
I've been writing vc++ for a few years now, but one feature I'd REALLY like to see would be to be able to easily set conditional breakpoints on a particular instance of an object. In fact, more object awareness across the board would be nice. I'd also like to be able to be somewhere in a windows message handler, and be able to see where the message had come from. I'd like to be able to call functions from the watch window like I could in DEC FORTRAN. I'd like to see the VC++ debugger be able to enumerate over collection objects using for_each, and examine COM properties as if they were variables. I want the VB watch and immediate windows for VC++.
You can't win Darth. If you mod me down, I shall become more powerful than you could possibly imagine
However, such a debugger, even if it did exist, probably wouldn't be incredibly useful. Sure, you could catch some errors. But most non-trivial programs I've written consist of so much on I/O (user & device) and system calls that a write-time debugger couldn't possibly tell me the values of enough variables such that it would be nearly as useful as a decent run-time debugger.
And c'mon, who wants to debug until it doesn't work? That's what testing is for. :-)