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.
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;}
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?