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?"

Re:Perhaps....

[Joseph Vigneau]

As anyone who's ever tried to use software knows, nobody uses debugging tools anyway.

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.

VB has one of those debuggers

[sdjunky]

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:The red-headed step child of development

[Azar]

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 [act-europe.fr]? 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.

Re:I'm sure loads of debuggers have got it...

[rvaniwaa]

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)

Re:Visual Basic debugger..

[MisterFancypants]

For the C/C++ people out there, try checking out the debugging facilities in Visual Studio .Net in general. The debugger for C++ is great as well. Edit & Continue support allows you to recompile code and keep debugging a running process in memory. Tons of options for conditional breakpoints (break anywhere if variable x changes). Support for automatic buffer overflow checking. Interactive variable watch that you can even call functions in (eg. you can set a watch on strlen(myString), it will display the result of the strlen call (and that's just one example, works with any function/method/data).

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

Reversibility is very hard

[mbessey]

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

Re:Still nothing to beat

[sbaker]

Nope - printf is still my debugging tool of choice.

I used to use gdb - but *ONLY* to find out what line my program
had crashed on - but then I discovered backtrace_symbols_fd
so I don't use *any* kind of a debugger anymore.

The art is to write code that's easy to debug.

Re:Debugger improvements

[Anonymous Coward]

- The WATCOM C/C++ debugger has reverse execution support. (No, I am not kidding.)

- Dumping data structure support is something that you can integrate into your application. That said, the MSVC++ debugger's data structure dumping is not that bad.

- The plug in idea is a good one. However, I believe that Soft-ICE may have at least some such ability.

I think perhaps the fact that the above post was moderated so high is evidence of an earlier post -- that nobody actually uses debuggers?

Re:Custom data type viewers.

[dair]

Often the data I'm working on is tough to just look at to see if it's right; being able to write something that would plug into the debugger to display some data would be cool.

This is one of the features in CodeWarrior 8 (at least in the Mac versions, and presumably the Windows version too). You can describe how the data should be organised so that the debugger can view it sensibly (e.g., where to find the string data in a std::string or that a CFloatRect is 4 floats), or write a plug-in to display it using your own code.

E.g., you could display an image as a square of RGB data and a square of alpha data - or as individual color planes, or whatever you like.

There was also a Mac tool a couple of years ago called General Edit (not by Metrowerks), although not a debugger as such - you type in a templated description of what your data looks like (with nested definitions, fields that rely on other fields, etc) and it pops up a structured view of the data. Very useful for poking around in data that normally you'd be trying to interpret with a hex editor, as you could tweak your decoding description until you had it right.

-dair

Re:Debugger improvements

[IanBevan]

Reversibility was available with the Borland IDE some years ago. Can't remember how well it worked.

Plugins is an interesting one. Although it's not a well known feature, the MS Visual Studio IDE allows arbtrary formatting of a datatype (it's specified in a configuration file IIRC). This is only formatting though, so there's no code to be executed and certainly no way of displaying the data graphically.

As for program control, try

if (mycondition) { asm int 3; }

Under Windows

if (mycondition) { DebugBreak(); }

The Visual Studio IDE can also set conditional breakpoints. Hit F9 to set a breakpoint, then open the Edit Breakpoints dialog box (Edit|Breakpoints) and hit the Conditional button.
Since we're here, I would very strongly recommend Jon Robbin's Debbugging Applications [amazon.com] book for lots of tricks and traps using Win32/ MS Visual Studio. All of the code there is win32 specific though, so not much use to Linux development. Amazon says it's out of print, but I see it in local nerdy bookshops from time to time.

Re:Teach people to use already available tools

[EvlG]

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?

Re:One Word: TotalView

[mz001b]

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.

Re:Perhaps....

[__past__]

Given that functions like "invoke-debugger" are part of the Common Lisp standard and hence every program can expect to be able to call them whenever it feels like it (although not much about how the debugger is supposed to work is standardized, for obvious reasons), yes, it usually ships with a Lisp app.

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 [franz.com] 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 [gnu.org] and Embeddable CL [sourceforge.net] support this. There is still less difference between the development/production environment than one would think: They also use plain .a/.so libraries to load compiled lisp code when you work interactively.

Re:Perhaps....

[giel]

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.