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?"
Although I'm guessing your reply was intended as sarcasm, I don't think it's that far from the truth. Debugging is a slow, laborious process. 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. That, coupled with configurable logging, eliminates many of the scenarios a debugger would be involved in, with the benefit of automation, reproducibility, and defect histories/log files. In my travels, I've seen as developers gain experience, they rely less and less on interactive debuggers, and more on automated testing and configurable logging.
Visual Basic supports a "watch" that allows you to break on condition such as when a variable changes at all or if a variable is set to a certain value. This is beautiful when trying to figure out how the currency value you just had disappeared. Add the watch saying when the currency = 0 and run the app so it breaks at ANY MODULE at ANY TIME.
This saves me time by not having to go into each module and watch the code to see if the value changes.
As for wanted features ( so as to not be totally off topic ) I really can't think of any that I would need per se. Since my favorite language is VB ( watch the flames poor in on that statement ) I have many tools for debugging that are perfect.
From the immediate window so I can run small snippits of code in break mode to the stack and watch windows.
Debuggers aren't flashy or glamorous. I don't know anybody that thinks debuggers are cool. The tools and pieces of a development environment that are going to catch a programmers eye first are what's focused on most. You look at a nicely developed IDE that's polished and slick, and you'll be impressed. It's eye candy that sells products more than anything else.
Sadly, most -programmers- even look at a development environment's debugger as an afterthought. IMHO, it's one of the single most important tools (if not THE most important) and it's what I check out first.
Have you ever used the Gnu Visual Debugger at the GNAT Libre software developers' site? It's a multi-platform (Linux/Unix/Windows), open-source debugger with a "different view" of the world. Check it out, you may be pleasantly suprised.
To do this in dbx do:
"stop at 99 if (x == 17)"
or in gdb:
(gdb) break main.C:99
Breakpoint 1 at 0x8048776
(gdb) cond 1 (x = 17)
(gdb)
main(i){(10-putchar(((25208>>3*(i+=3))&7)+(i ?i-4?100:65:10)))?main(i-4):i;}
Whatever you think of Microsoft, the debugging support in Visual Studio .Net is very top notch and well supported in all languages (C#/VB/C++ (both managed and unmanaged)).
You can implement reversibility on a per-thread basis (though that's harder than it sounds, in my experience). For multiple threads, it's basically impossible.
It's much easier to implement back-stepping in a processor simulator or virtual machine than it is in a native-code debugger. Unless you single-step through all the instructions, keeping snapshots of all the relevant state along the way, you can't go back.
And if you do single-step, the performance will likely be so poor that you might as well use a simulator.
-Mark
You are dead on here.
How many ppl here are clamoring for conditional breakpoints, when VS.NET can do this already?
Or clamoring for the ability to see what changed your variable, no matter where it was changed? Breakpoints on memory can do this too. In VS.NET I just set a breakpoint on a given memory address, and anything the address changes, it takes me right to the instruction (or statement, if it has src) that changed it. Absolutely critical feature for tracking down memory corruption.
But how many people know about these facilities?
I agree, Totalview is a really impressive program. When you have a bug that only manifests itself on 16 or 32 (or more) processors, print don't help as much. Stepping through code with totalview can really help figure out what is going on.
The standard image shipped with CMUCL is about 20 MB on my FreeBSD box. This contains the whole standard library, including the compiler, debugger, profiling and tracing tools, embedded documentation (docstrings attached to functions/variables available programatically, like Python also has now) etc. To that, you add your own code, either as external libraries that get linked at runtime or integrated in the image - you load everything you wrote in a running image, both code and possibly data, and dump its state, so you don't have to re-load it on startup.
It is possible to get rid of functionality, but I doubt it's frequently used. 20 MB for the runtime system are not too much, compare for example with a Java runtime environment (or a basic Unix system, that could be regarded as Cs runtime).
Some commercial Lisps, for example Allegro Common Lisp support a more "conventional" way of delivering apps, as standard executables without the need for a runtime. Given that Franz charges higher license fees if you want to include the compiler/debugger in your app, I guess there is a way in ACL to get smaller executables.
Yet another option is compiling to C, and use standard OS tools like GCC for the final step. Gnu CL and Embeddable CL support this. There is still less difference between the development/production environment than one would think: They also use plainProgramming can be fun again. Film at 11.
I prefer verbose logging too. I've been working with WebSphere Application Developer during the last year and I've never used the debugger. However verbose logging - IMHO - should be considered as a form of debugging too. Sure, it's not the boring act of step-by-step stumbling through control structures and loops glaring at a huge set off watches, but instead it focuses on what is important in a certain context (if logging is done properly) and is works much faster, because the result simply stays in the form of a log which one can take all the time needed to examine.
An important pro of verbose logging to traditional debugging is that proper log statements preferably combined with assertions which validate the state of an object at runtime also provide very usefull documentation of a program. The remaining contra is extra code slowing down execution, even dramatically depending on the log format (imagine the time needed to format date/time information for each 5 or so lines of code).
Comes to my mind the fact that object oriented languages use runtime linkage for virtual methods at great scale. Hence it should be possible to keep two versions of code, one containing debugging code and one that has been cleaned - eg. by a modified class loader for example, whic removes all calls to a classes from a certain package. This should enable switching at runtime from a clean non-logging version to a logging-version, if a certain condition is met. For example during a suspicious error, or simply a flag a user can set at the moment he or she detects a bug. This means that even production versions of software could be equiped with shiploads of logging possibilities having nearly no affection at all to their execution speed.
giel.y contains 2 shift/reduce conflicts