Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

How Would You Improve Today's Debugging Tools?

Cliff posted more than 11 years ago | from the there's-always-room-for-improvement-right dept.

Programming 731

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

cancel ×


Sorry! There are no comments related to the filter you selected.

First post. (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5041592)

I am better than you.

Re:First post. (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5041608)

How come all the AC's get first post? By all means the cowards would be hiding in the corner, from the big bad wolf.

Second post. (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5041605)

This post claimed in the name of Jewish superiority.

Perhaps.... (5, Funny)

foxtrot (14140) | more than 11 years ago | (#5041607)

Why do you think so much effort been invested in areas such as advanced modelling tools but so little in improving debugging tools?

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


Re:Perhaps.... (5, Informative)

Joseph Vigneau (514) | more than 11 years ago | (#5041662)

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.

Re:Perhaps.... (4, Funny)

L. VeGas (580015) | more than 11 years ago | (#5041665)

Agreed, this is pointless.

Anyone that's ever been buggered knows that you can never be debuggered.

It's like the old joke:
Q--What's the difference between Madonna and a lightbulb?
A--You can unscrew a lightbulb.

Re:Perhaps.... (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#5041699)

Yeah, just ask this poor bastard []

This link brought to you by the Goatse Link Preservation Society

Re:Perhaps.... (2, Insightful)

Y Ddraig Goch (596795) | more than 11 years ago | (#5041784)

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.

All your need is a little of this... (2)

jpt.d (444929) | more than 11 years ago | (#5041613)

Project Builder absolutely sucks for debugging on its own. But, I use it for break point management, but from there I use the GDB console it has. I know dick about getting gdb upto that point, but PB does it nicely. Then I can use p for a normal inspection, and po for an object inspection. I like it. If it weren't for the GDB console, PB would really suck debugging. But with it, it rocks!

This is no surprise -- It's not PB's job (2)

krog (25663) | more than 11 years ago | (#5041624)

Project Builder is meant to integrate (as you said, through breakpoint control) with GDB. It is not meant to perform debugging on its own.

It's a wonderful development environment -- Project Builder for the code, Interface Builder for the GUI, and GDB for debugging.

Easy solution (4, Funny)

stratjakt (596332) | more than 11 years ago | (#5041616)

Dont debug.

Eventually someone else will find the bugs and fix them for you at their own expense.

This is how the Open Source programming model works.

I'm sure loads of debuggers have got it... (4, Interesting)

koali (175176) | more than 11 years ago | (#5041621)

But I'd like to be able to create 'conditional' breakpoints (i.e.: stop at this line when i==47).

Other than that, I'd like generalized hot-swapping of code and 'step back' (which I don't know if it's always factible); or at least be able to view a variable's history.

Shame that my IDE of choice (Eclipse) doesn't (AFAIK) support those.

VB has one of those debuggers (5, Informative)

sdjunky (586961) | more than 11 years ago | (#5041684)

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.

Re:VB has one of those debuggers (0)

Anonymous Coward | more than 11 years ago | (#5041719)

Since my favorite language is VB...

Someone has karma to burn! :)

Re:VB has one of those debuggers (4, Insightful)

Anonvmous Coward (589068) | more than 11 years ago | (#5041804)

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

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

Khomar (529552) | more than 11 years ago | (#5041718)

I definitely agree with the previous post (no moderation points though *sigh*). I have also had times where having the ability to set a variable value at the time of debug would have been useful in tracking down hard to reproduce bugs by forcing a different code path -- like, for instance, testing an error condition that could be difficult or time consuming to generate (out of memory, locking issues, etc.). When dealing with a customer's complaint in a situation you have never seen before, having the ability to tweak variables to match their situation would be useful.


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

MisterFancypants (615129) | more than 11 years ago | (#5041730)

Yeah. Visual Studio .Net does this, and many more things, when it comes to advanced breakpoint support. It is REALLY NICE to go in and tell it to break on any line when a certain variable changes, in those cases where you see a variable is changing at some point but you're not sure exactly where it is happening.

It pains me greatly to have to use lesser debuggers than the one in Visual Studio when I'm developing code for non-Windows platforms. The extensive breakpoint support, edit and continue, etc seemed a bit like fluff to me when I first started using them, now I find it hard to live without them.

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

technomom (444378) | more than 11 years ago | (#5041756)

IBM's Websphere Application Developer V5.0 (based on Eclipse 2) has watch and also has a general "break the nth time you hit this line" breakpoint.


Re:I'm sure loads of debuggers have got it... (5, Informative)

rvaniwaa (136502) | more than 11 years ago | (#5041760)

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)


Re: gdb supports watch and conditional break (0)

Anonymous Coward | more than 11 years ago | (#5041798)

gdb also supports many types of breakpoints. You can use the "watch" command to break execution when a variable changes, or you can set conditional breakpoints (see "help breakpoints" for the options available to you).

Personally ... (2, Funny)

trexl (16434) | more than 11 years ago | (#5041623)

I'd like to make those damned debuggers less harmful to humans. It's such a pain to leave the house or apartment when you're trying to get rid of pests.

I am a command :) (5, Funny)

jdavidb (449077) | more than 11 years ago | (#5041628)

When I got my first job I was thrilled to be able to log in with my initials, jdb, instead of using the crummy initials and numbers ID I'd had at school. Imagine my surprise one day when I left the "cd" off a command to change into my home directory from /home and instead of an error discovered the Java debugger! ESR and RMS, eat your hearts out. :)

My only regret is jdb is a Java command, not a Perl command.

Re:I am a command :) (5, Funny)

Frothy Walrus (534163) | more than 11 years ago | (#5041661)

I do not use the same username naming convention as you. Good thing.

--Richard Muldoon

Now _that_ was funny. (0)

Anonymous Coward | more than 11 years ago | (#5041751)


Re:I am a command :) (0)

Anonymous Coward | more than 11 years ago | (#5041759)

You think you've got it bad!

-- Robert Matkin-Forsyth

Forget the Debugger (3, Interesting)

sohp (22984) | more than 11 years ago | (#5041630)

Write unit tests. Write acceptance tests. Write regression tests. Give the customer the ability to execute the acceptance tests automatically and get immediate feedback on what's working an what remains to be done.

Look at the story subject again... (4, Insightful)

DoseKapital (639545) | more than 11 years ago | (#5041737)

It seems like you're responding to: "How Would you Improve Software with Debugging Tools?"

That's not what we're talking about...

We're talking about: "How Would you Improve Today's Debugging Tools?

I guess you would add features to help automate unit tests, acceptance tests, and regression tests and figure integrate it with debugging features?

Re:Forget the Debugger (0)

Anonymous Coward | more than 11 years ago | (#5041792)

So you want the customer to be your qa department and run YOUR acceptance test? I don't think so.

Software Quality is the DEVELOPERS responsibility. Quality Assurance, does just that, it ASSURES that the developer is doing his/her job.

Unit testing is a good place to start. The cost of fixing a bug increases the further the code goes down the pipeline to the customer. This is the case for open source and commercial software.

Stop writing shitty code and make sure your work is peer reviewed to prevent the forest through the trees syndrome.

Re:Forget the Debugger (1)

FortKnox (169099) | more than 11 years ago | (#5041802)

are you suggesting that with all of those you won't have bugs?
If you have bugs, some help from a debugger is a nice gesture (but not every little wizbang in a debugger that you can find! Read my other post for my opinion).

Still nothing to beat (4, Interesting)

UncleFluffy (164860) | more than 11 years ago | (#5041633)

fprintf(logfile, ...

and the mighty grep

Improved Variable Watch (5, Interesting)

Greenisus (262784) | more than 11 years ago | (#5041640)

My favorite debugging tool is to use watches while stepping through code. I think it would be nice if we could highlight a watched variable and get a list of every statement (with stack traces if you like) that changed that variable prior to the current line of code.

Re:Improved Variable Watch (2)

Viking Coder (102287) | more than 11 years ago | (#5041758)

Doesn't work when someone clobbers your memory.

But it's kind of a neat idea. It would certainly be expensive, though.

Debugger improvements (5, Interesting)

exp(pi*sqrt(163)) (613870) | more than 11 years ago | (#5041643)

  • Reversibility. I'd like to be able to step backwards through code. No, this isn't a joke. Only a small amount of information needs to be stored as each instruction is executed in order to have an emulator go backwards again. You don't necessarily want to run an entire application reversibly. You might want to run a small loop until it crashes and then work backwards to find the cause.
  • Easy plugins I want to easily be able to load my own custom code into the debugger. For example I might want a custom routine to conveniently display a custom datastructure, or even give a graphical representation of some data.
  • Program control. More cooperation with the code itself. I'd like the debugger to provide a library against which I can link my code so that the code being debugged can control things like which variables are being watched and which breakpoints are active. I could then easily have breakpoints that are enabled only under certain conditions. Especially useful when the best way to detect those conditions is for the code itself to figure it out.

Re:Debugger improvements (1)

p3d0 (42270) | more than 11 years ago | (#5041704)

Forget plug-ins. In gdb, you can just code up whatever debug facilities you want, either as a script (is possible), or even by adding it to the gdb code itself. If you have never tried the latter before, you should--it's remarkably easy.

Yay for Free software.

Reversable debugger (3, Interesting)

mahlen (6997) | more than 11 years ago | (#5041713)

For Java coding, take a look at RetroVue [] , which indeed lets you wind back the clock and see exactly HOW that reference became null (among other things).


Reversable debugger (2)

interiot (50685) | more than 11 years ago | (#5041787)

For embedded programming, logic analyzers will let you store X number of steps before your program crashes. Of course, they cost $80,000, but it's still an alternative for the top 10% of employees of the top 100 tech companies...

I've got 4 words for you (0, Troll)

blahlemon (638963) | more than 11 years ago | (#5041644)

Developers, developers, developers, developers.

Teach people to use already available tools (5, Insightful)

rvaniwaa (136502) | more than 11 years ago | (#5041647)

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

I'm not a professional developer, but... (5, Insightful)

reimero (194707) | more than 11 years ago | (#5041649)

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.

what's wrong with debuggers? (1, Funny)

Anonymous Coward | more than 11 years ago | (#5041654)

No dancing girls!

Add one or two beautiful dancing girls to every debugger, and they'll sell like hotcakes.

Problem Solving Skills (2, Interesting)

kvn299 (472563) | more than 11 years ago | (#5041660)

Debugging is essentially problem solving and if you don't have well developed skills doing that, then it's not going to be very easy to do. However, every person thinks differently and hence approaches to problem solving varies. It seems to me that although computers can help narrow down the scope of this issue, in the end, it's the brain that is the most powerful tool.

Remember those high school days of comparing the green text on your TRS-80 monitor to the print in your Softside magazine. Now that was fun... har har.

Visual Basic debugger.. (3, Interesting)

mumblestheclown (569987) | more than 11 years ago | (#5041664)

As much as everybody here likes to make fun of Visual Basic, I encourage all to have a look at VB's debugger. While there are a few improvements here and there that could be made, in general it far, far surpasses anything else that I have seen out there. (I have yet to play with am referring here to VB6).

Re:Visual Basic debugger.. (3, Interesting)

stratjakt (596332) | more than 11 years ago | (#5041721)

I use it every day, and take it for granted sometimes. I miss it when I'm using another language and lacks its features.

The call stack is at your fingertips, I add/remove conditional watches with a couple keystrokes, stepping into, out of, and over functions, and the immediate pane makes a great scratchpad/interface to the internals of the program. You can break on all errors, unhandled errors, or arbitrarily.

It wouldnt be nearly as easily to quickly put together apps in VB without it's debugger. It truly turns a half-assed language into a really good tool for rapid prototyping.

Re:Visual Basic debugger.. (1)

leecho (627827) | more than 11 years ago | (#5041808)

I can't see anything that VB's debugger has that Eclipse doesn't, and Eclipse's got one of the best Java debuggers I've ever used, despite some bugs with recursive data structures that I hope that get fixed soon (create a List and add itself to it, go to the variables and press '*' to unfold the whole tree, and *boom*).

Re:Visual Basic debugger.. (0)

Anonymous Coward | more than 11 years ago | (#5041788)

the VB IDE/debugger is much better than a lot of other commercial products today.

But it is crap compared to what smalltalk or some common lisp environments were doing 20 FSKING YEARS AGO.

This is truly depressing. Perhaps what is needed is not so much `new' ideas, as to actually follow what *good* ideas have been used before.

The commercial programming community is amazingly ignorant of what has been done before. Laughable claims of 'innovation' come out every year, and the whole teach-yourself-something-simple-in-21-days crowd keep lapping it up.


Re:Visual Basic debugger.. (3, Informative)

MisterFancypants (615129) | more than 11 years ago | (#5041793)

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

Debuggers cause problems, and are IDE-dependent. (1)

$$$$$exyGal (638164) | more than 11 years ago | (#5041666)

I know this sounds cliche. But don't many many developers hate debuggers with a passion? They can be extremely useful at times, but they can definitely get in the way. There has been at least 3-4 times in my career when a debugger was actually causing problems to happen! That ain't right.

Also, using a debugger often requires learning a new IDE. The best ones are usually integrated with some IDE that I otherwise hate. I understand why that would be the case, but I still hate it. I don't want to learn a new IDE!

--naked []

Maybe they don't really need improvement (1)

elsegundo (316028) | more than 11 years ago | (#5041668)

All I want from a debugger is to be able to step through code and see values of my variables at certain points and verify program flow.

Most often I'll use it as a tool alongside using printf's or println's and (gasp!!!) just sitting down and reading the code in question.

Debuggers are useful, but I see too many freshouts using them exclusively to fix code, rather than just looking at the code to analyze the design.

How about a "previous" command? (2, Interesting)

jimmc (543668) | more than 11 years ago | (#5041671)

I want a debugger that can back up execution a line at a time. That way I can run my program until it crashes, then single-step it backwards until I find the problem.

Back at Silicon Compilers, we actually had a hardware simulator that could do this. It was a pretty neat trick: it would checkpoint the entire system state every few hundred cycles, then when you wanted to back up, it would restore to the most recent checkpoint and run forwards until it got to the right clock cycle, the one just before where you asked it to back up.

Re:How about a "previous" command? (1)

NullProg (70833) | more than 11 years ago | (#5041750)

The watcom debugger does this. It's called unwind/rewind stack. Still available at


The first thing I would do... (2, Funny)

Giant Ape Skeleton (638834) | more than 11 years ago | (#5041672) make sure the debugger checks for GPL violations.


Re:The first thing I would do... (1)

Anonymous CowWord (635850) | more than 11 years ago | (#5041743)

Um, how exactly do you use a debugger to check for a GPL violation? I think you are confused by what the GPL is :) The GPL is a lisence (sp), not a standard for coding.

Real Men Don't Use Debuggers (3, Redundant)

dilute (74234) | more than 11 years ago | (#5041674)

Strategically embedded print statements - the time-honored way to find bugs.

That plus printing out and actually READING the code. Amazing what you can find by walking out of range of the screen and keyboard and just reading through the stuff.

Re:Real Men Don't Use Debuggers (1)

patter (128866) | more than 11 years ago | (#5041742)

Debugging without an interactive debugger is much more fun.. you get to see such gems as:

printf("I'm in the fscking DoStuffRightThisTime() function!!");

I've yet to see a function in MSVC++ that lets me curse when I'm frustrated by something not doing what I thought it should be ;). If I'm really frustrated I can always loop a few hundred times with my favorite expletives :P.

println debugging (4, Interesting)

kisrael (134664) | more than 11 years ago | (#5041675)

I don't know if it's my greatest failing or greatest success as a developer, but I tend to be a println debugger all the way.

Recently I remember seeing some justification/defenses of this technique, I think it's sometimes called "logging based debugging".

When something goes wrong I figure out the related assumptions I'm making, and then test 'em by output to STDOUT or STDERR or a file. It avoids some of the "Heizenbug" problems debuggers can bring on (so long as dumping output can be reasonably expected to be reliable w/o bringing on crossproblems) and by thinking of your assumptions, you're tying into principles similar to "write tests first", part of XP practices.

One set of things this doesn't handle well is memory leaks and bottlenecks and looking out for runaway object creation and the like, but garden variety debuggers usually don't cover that too well either, you need special profiling tools anyway.

Debuggers are mostly useless (2)

Julian Morrison (5575) | more than 11 years ago | (#5041676)

Real debugging uses (1) printf calls to trace execution path, dump variables, and detect the crash point down to the nearest few lines (2) eyeballs and brain to spot the goof now its position is locked down. Debuggers are just for the wierdass bugs, and mostly they break differently in those cases anyway, because they're singlestepping not running full tilt.

A good debugger for those cases whern one's needed is DDD [] .

Durr (2)

mao che minh (611166) | more than 11 years ago | (#5041677)

"How Would You Improve Today's Debugging Tools?"

Make them work better at debugging. What a pointless story/question this is.

Re:Durr (1)

blahlemon (638963) | more than 11 years ago | (#5041770)

Actually I think that they were looking for something a little more constructive then stating the obvious! lol. Something like "Have debuggers understand how to program independantly so they can parse through the code and identify the errors for you"

You know, like In Soviet Russia your code debugs YOU!

Eclipse debugger (2)

LadyLucky (546115) | more than 11 years ago | (#5041678)

Is miles in advance of earlier versions of debuggers. Change code at runtime, you sexy beast.

some ideas on why debuggers are in this state (5, Interesting)

Shaleh (1050) | more than 11 years ago | (#5041682)

a) it is hard to make money on debuggers

b) making a good debugger is definately not easy

c) many developers prefer puzzling out the code on pen and paper then walking it in a debugger. Quite a few I have talked to believe that they make better code if they can solve the problem without resorting to debuggers. This BTW is why Linus does not like kernel debuggers.

d) most of the debuggers are good enough and as we all know from open source, a good enough solution will live forever. The existence of a debugger that mostly works gives most people a reason to spend their time elsewhere.

In my experience I have truly benefited more from programs like Purify or Insure (and now the great valgrind) than I have from a debugger.

Don't carry just one knife... (1)

ivrcti (535150) | more than 11 years ago | (#5041685)

I work with a variety of IDE's and tools so my debuggers range in quality from acceptable to non-existant.

Therefore, I make every effort not to depend entirely on my debugger. I use a combination of assertions, exceptions and logging to make sure that when something goes out of bounds, the reasons and the states are there in black and white.

Yes, it takes a bit longer to code, but it makes testing, debugging and especially exception path fixes much, much faster.

Ignore the MIT Media Lab (2)

timeOday (582209) | more than 11 years ago | (#5041687)

Every time I hear something from the MIT Media Lab, it's a searing indictment of something terribly wrong software engineering or computer science, and how they are here to fix it with avatars or wearable computers or something. And then you never hear about the idea again.

Official Rant! (0)

Anonymous Coward | more than 11 years ago | (#5041688)

Well howto improve debugging tools.... simply hand them over to the GNOME developers, they know what they are doing first of all the default configuration mechanism get replaced with GConf (Windows Registry) System and then If it's a GUI client, we change the Button Ordering to make the application suck as much as even possible.

ddd (1, Insightful)

Anonymous Coward | more than 11 years ago | (#5041689)

ddd's visualization capabilities are terrific. You might be able to get rid of the graph paper.

Why? (1)

stagmeister (575321) | more than 11 years ago | (#5041691)

Why should I have to pay for a debugging tool, or write a debugging tool? I've had the best debugging tool with me all along -- my brain.

Good ol' command line. (2)

grahamlee (522375) | more than 11 years ago | (#5041695)

Why do you think so much effort been invested in areas such as advanced modelling tools but so little in improving debugging tools?

I think that very few people use them often enough to justify spending lots of R+D hours+$$$ on the debugging tools. How often do you see "-DDEBUG" in Makefiles? You'd think that if debuggers were so useful, you wouldn't need to switch in debugging code in the app. But many programmers feel more at home locating the bug using printfs or similar, then just reading through the code. Pencil and paper often helps too.

Something I learnt from my BASIC days, which I still use in *sh/Python code is the use of the interactive interpreter (a.k.a. "command line" :-). This is especially helpful when trying to debug someone else's code - you can enter it line-at-a-time and see what happens. Yeah, so gdb can do that. But you think more about the code if you're typing it in yourself than you do repeatedly pressing the "step" key.

I have used debuggers such as disassemblers and monitors as well as gdb, the Delphi debugger etc. While they have uses I just don't find they do anything sufficiently different from manual debugging to make them worthwhile.

There's my £1E-2 :-)

The debugger is half the story (1)

The Bungi (221687) | more than 11 years ago | (#5041700)

If your application is badly designed, debugging it is going to be crappy anyway. A good application design has to incorporate things like unit testing (instrumented or not) and a decent state machine management infrastructure.

If you're using a language like VB or Delphi debugging is simple and almost inviting. I think that has always promoted bad application design. "Oh, that didn't work. OK, let's try this. Oh, that didn't work. OK, maybe this will work" and so on.

If you're writing applications in C or C++, and especially as you get closer to the system, you learn to be more careful about what your application does because it's very difficult to change direction in mid-flight. It also forces you to think about what you're doing a lot more. I.e., you have to know what you're doing. Impressive concept, but frequently lost on today's "programmers".

IMO, something like the "edit and continue" feature found in modern integrated IDEs like VB is a bad idea.

Fix the programmer, not the program (3, Interesting)

doi (584455) | more than 11 years ago | (#5041703)

A debugger does nothing to improve software, commercial, professional, or otherwise. All you have to do is look at Bugtraq to prove it.

The best way to learn how to write bug-free code is to NOT use a debugger at all. Every programmer should begin writing code in Notepad or some other basic, no-frills text editor. Just like everyone should learn how to type on a typewriter and not a computer. It forces you to NOT make mistakes, instead of correcting them (you don't have to "debug" a program if you don't put the bugs in in the first place!) It forces you to slow down and think about what you're doing, instead of blasting through a procedure and then run the debugger on it. If everyone programmed for at least a year without ever using a debugger, the quality of their code will improve far greater than any fancy IDE debugger will improve it.

How would I improve todays debugging tools? (0)

Anonymous Coward | more than 11 years ago | (#5041705)

I'd make them totally automagic. All you'd have to do is click the icon and it would debug your code. It would fix mistakes without even prompting. It would modify and streamline the code to make it fast and efficient. It would cure all buffer overflows, memory leaks, heap corruptions, everything. It would document the code, line by line in english your mother could understand. It would have a super cool GUI that was easy to understand and showed you a porn slide show while it was churning through the code.

It would be so totally awesome that Microsoft would beg me to sell it to them. But, it would be licensed under the GPLv3, which would be just like a BSD license but, include a clause excluding Microsoft and their affiliates from even looking at the code, much less using it.

It would be the most awesome debugger the planet has ever seen. Yep. That's how I would improve it. Why, what were you thinking?

Debugging? (1)

grub (11606) | more than 11 years ago | (#5041706)

What's that? I trust Microsoft [] to run the show!

I'd get rid of them (2)

greechneb (574646) | more than 11 years ago | (#5041707)

Too many people were dependant on them when I took programming classes in college. They'd write code carelessly, and then run it through the debugger, and do exactly what it said, instead of learning to code properly.

Current debuggers do the job. (2)

Java Pimp (98454) | more than 11 years ago | (#5041711)

It's been my experience that current tools like Visual Studio are just fine. Once in a while maybe a kernel level debugger. Most often bugs are the result of some logic error in some algorithm you just know should be working. And with a little tracing and memory dumps you can find the problem.

However, if the error is such that cannot be tracked down within a reasonable amount of time and isn't confined to a small section of code then I wouldn't consider it a bug but a flaw in the design. A good design would eliminate such difficult bugs and then the smaller ones only need the simpler tools we currently have to track them down.

In my opinion, the advances in modeling tools help reduce the number of potential problems so there isn't as much of a need for advanced debuggers.

I'm sure some will disagree but this has been my experience. I've redesigned sections of code to eliminate an elusive bug and it's made for a more solid application.

Debugging tools only help so far (1)

russx2 (572301) | more than 11 years ago | (#5041712)

Of course, the problem is, debugging tools will only help you track down bugs that you are looking for - and hence bugs that you know exist.

It is not the case that software companies and the like intentionally release software with no known bugs (cue: microsoft puns) it is they do not know they exist. No amount of debugging tools will help you find these bugs.
The general methodology for many programmers (from amateur to supposedly professional) is to write some code and do a few quick tests. Perhaps throwing in a few -1's and out of range values to check for error checking. The caveat here of course is that these checks don't always apply to a real world bug which the programmer hasn't even contemplated. It is poor planning and bad design that inevitably leads to the bugs - as the author of this post suggests, maybe we should all spend more time with our graph paper and pencils before writing the code.

A debugging tool is there to help fix bugs that you know exist - unfortunately it is often the userbase that has the job of finding them.

Debugging Tools (0)

Anonymous Coward | more than 11 years ago | (#5041714)

If you used a Smalltalk debugger, you wouldn't be complaining so much. Give it a try sometime.

It's a deep complex issue (1, Interesting)

Jack Wagner (444727) | more than 11 years ago | (#5041722)

I think we will come full cycle on this and start to have success when we are able to peel away the abstract levels of encapsulation and stop attempting to hide the data away by using high level constructs.

I've seen that most of the high level languages (java, Visual Basic, c#) promote RAD via lack of formal trainging. Thus the real problems start to show up when someone who has learned the syntax but knows nothing about how IPv6 packets handle little endian sockets tries to debug a complext multi threaded app and spend all their time basically guessing instead of analytically and systematically debugging the application.

Fred Brooks in the "Mythical Man Month" stated that unless a language is written in the same language that you increase the time to debug it by Olog(n) and that's true today when you look at java (not written in java) or perl or c# as opposed to languages like C and Fortran that are optimzed for debugging by being written in C and Fortran. Much of what Fred wrote about is not pertinat any more that this one still stands the test of time.

Basically it's a low level problem and not a "debugging tool" problem as I see it.

Warmest regards,

Interactive development (0)

Anonymous Coward | more than 11 years ago | (#5041724)

Having a more interactive development environment makes debuggers much less necessary.

When building the project is expensive, then debuggers really help because it's "cheaper" to fight a debugger than it is add a "printf" into the code.

But when the turn around is very quick, then "printf" and simple functional tests make things MUCH easier.

I haven't used a debugger is years.

Best way to debug : Better Code (3, Insightful)

Viking Coder (102287) | more than 11 years ago | (#5041727)

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.

Easy--use Visual Studio .NET more (0, Flamebait)

mattc58 (603979) | more than 11 years ago | (#5041732)

Best IDE and debugger around, bar none. To be honest, one of the first debuggers which actually works all the way through. You can debug from a POST event on a web page, through the code-behind code, through the middle tiers, and all the way into the stored procedures. Nice.

Debuggers:The red-headed step child of development (3, Informative)

Azar (56604) | more than 11 years ago | (#5041733)

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.

My Dream Debugger (5, Interesting)

Rary (566291) | more than 11 years ago | (#5041734)

Some of these features exist in current debuggers, and some do not. What I want is all of them.

1) The ability to set conditional breakpoints.
2) The ability to see not only a variable's current value, but a stack of all of its previous values.
3) The ability to select a variable's previous value and jump to the line of code that set it to that.
4) The ability to change the value of a variable at any point.
5) The ability to add/change code on the fly.
6) The ability to jump into the debugger at any point in the program, even when I hadn't planned to before running it.
7) Auto-logging of method calls and (optionally) variable values, to be started and stopped as I see fit either while stepping through code or running it.

That's all that comes to mind off the top of my head.

I asked my boss.. (3, Funny)

Anonvmous Coward (589068) | more than 11 years ago | (#5041736)

... about Debugging Tools. He felt that engineers should just learn to write software without bugs in it.

He felt? Did he feel you up? (0)

Anonymous Coward | more than 11 years ago | (#5041796)

And that's his problem - he didn't think.

I wouldn't let the retards at microsoft (1, Funny)

aroundsomewhere (244353) | more than 11 years ago | (#5041740)

I wouldn't let the retards at microsoft work on any more code for the IDE. Then at least it wouln't get any worse.

Why? Because quality doesn't pay the bill. (1)

Gadzinka (256729) | more than 11 years ago | (#5041747)

It is simple.

Quality and/or security (which is often the same thing) doesn't pay the bill. Features pay the bill, runaway version numbers pay the bill.

It would be the same in other industries if it weren't for cunsumers' rights and vendor's liability. Unfortunatelly there is no liability for software vendors, so the QA is still in its infancy as it was few decades ago.


The problem is with debugging, not the debugger (2)

AlphaHelix (117420) | more than 11 years ago | (#5041753)

One major problem is that the very concept of debugging is problematic. It assumes that you will make mistakes, and that the only way to track down mistakes is to painstakingly find each one. This process takes O(n) time, but the number of bugs grows more like O(exp(n)) with the program size, so when programs become non-trivial, you'll never be able to track down all the bugs.

What's actually needed is more intelligent languages and automated code checking tools, as well as better code review and coding practices. Strict code review and coding practices help make programming more like a real engineering endeavor, instead of the fly-by-the-seat-of-your-pants garage hack-fest that seems prevalent in a lot of existing code. But, the real challenge is to develop languages with features like the ability to detect potential problems in code using partial evaluation, and alert the programmer at compilation time rather than run time.

Basically, we're still in the hunter-gatherer stage of software development, and the Bug Problem needs to be fixed by a fundamental shift in paradigm that can move us beyond the need to deal with "bugs" explicitly. Until then, a snappier debugger interface and new debugging features will only have marginal impact on the ability to develop fault-free software.

My debugger (2)

Jonboy X (319895) | more than 11 years ago | (#5041754)

System.out.println(). Works fine for me most of the time. If not, I can print a stack trace and see what's going on...assuming Java, of course.

The only place I've seen that a debugger comes in handy is stepping through poorly understood code. Really, the code should be documented well enough to explain what's going on, but that's rarely the case.

People...Bugs who need People... (2)

mcmonkey (96054) | more than 11 years ago | (#5041763)

At some point debugging comes down to, the computer can only do what people tell it to do. A lot of advancement has been made in making it easier for programmers to communicate with computers. Advances are made in methods for reporting just what is being done or why something can't be done. But in the end, the bottleneck is the programmer who has sit down with his pencil and paper and slide rule and figure out, "is this really what I want to tell the computer to do?"

Simple... (1)

Wireless Joe (604314) | more than 11 years ago | (#5041764)

Remove the bugs.

Alternatives to traditional debuggers (2)

mbessey (304651) | more than 11 years ago | (#5041767)

There's an article in the latest issue of Embedded Systems Programming [] about using visualization tools for debugging. Well worth reading.


Debugging (3, Insightful)

bytesmythe (58644) | more than 11 years ago | (#5041774)

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.

As somebody who uses printf... (1)

cbcbcb (567490) | more than 11 years ago | (#5041775)

I did see a demo of a Java debug system which generated a log during execution and allowed the user to look at what was the full state of the program at any point during its execution. Very cool.

As somebody who uses printf, I would like the facility to add printf's retrospectively without having to recompile and re-run the code. printf debugging is great because it can be extremely context sensitive to the state of the program.

Another advantage of printf debugging is that you can compare the behaviour of two similar versions where one displays a bug, and see where the buggy one's behaviour is differing from the working version. Perl is a great tool for accounting for differences which are expected

Other than that, I find debugging on x86 is a pain because the assembler is much harder to read than a RISC instruction set like ARM. I don't know what I'll do if I ever have to debug something on IA64 :)

I did see a demo of a Java debug system which generated a log during execution and allowed the user to look at what was the full state of the program at any point during its execution. Very cool.

More is bad (5, Insightful)

FortKnox (169099) | more than 11 years ago | (#5041777)

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.

Perhaps it's an economic issue. (4, Interesting)

RelentlessWeevilHowl (451367) | more than 11 years ago | (#5041779)

Why do you think so much effort been invested in areas such as advanced modelling tools but so little in improving debugging tools?

A debugger is going to help you find and fix the bugs that got through:
  • Requirements analysis
  • Specification analysis
  • Design analysis
  • Code analysis

Studies have shown repeatedly that the cost of fixing each bug increases at each stage. So if you are going to invest $1000 in new development tools, is it more economical to buy tools to detect bugs when they're cheap, or when they're expensive?

Great Development Tools (2, Interesting)

repetty (260322) | more than 11 years ago | (#5041782)

The original poster's questions are all loaded with the presumption that something is wrong with using graph paper, pens and pencils.

Why on earth do so many people feel all development tools need to be built into a software debugger or they are inferior???

One great tool he did not mentiong is the napkin.

Java (2)

gUmbi (95629) | more than 11 years ago | (#5041791)

Exception stack traces are a godsend.


Slightly OT (2)

buss_error (142273) | more than 11 years ago | (#5041794)

More thought to how a problem is solved BEFORE coding would solve a lot of debugging problems. I've seen too many programmers start coding first thing when they are given a problem. Sometimes the answer isn't code per se, but how you think about the problem.

Good example is a damaged database. If you say "You have a damaged record", the customer says, "Well, fix the record and get all my data back!". If you say, "All your data is lost, but I think I can get most of it back if I get rid of this one record.", the customer says "DELETE that record!".

Interpreted languages could... (1)

number6x (626555) | more than 11 years ago | (#5041797)

Interpreted languages like perl or python could highlight bad syntax by running the code you are typing through parts of their own interpreter at given intervals. Kind of like an 'autocorrect' feature in some word processors.
I think I would find it more annoying than helpful.
I used to always lint my C code from Emacs when I was using C all the time. Does that count?

Getting it right the first time (5, Interesting)

theonetruekeebler (60888) | more than 11 years ago | (#5041803)

Okay, so debugging hasn't gotten any better in the last couple of decades. I gotta say it's because the focus of methodology research has been on the development process itself, and that's an extremely good thing.

The more work goes in before you get to the debugging stage, the less buggy your product will be. A well-designed system does not need as much debugging later. I know I'm idealizing, but I've seen this bear out, especially when version N > 1 comes out and it's been hacked to smithereens because of poor design choices in the previous iteration.

Probably the most amazing bit of self-fulfilling prophecy you'll ever hear on a software project is a manager saying, "We'd better start coding now, because we're going to have a lot of debugging to do."

As for catching things ahead of time, I've always put breadcrumbs in my code to spew to stderr or a Java error console class or wherever. Very easy to #ifdef out later and trivial to turn back on later.

Use Ninnle (0)

Anonymous Coward | more than 11 years ago | (#5041814)

Simple. Use the debugging tools that come bundled with Ninnle Linux!

Have you tried (1)

rabbits77 (453747) | more than 11 years ago | (#5041815)

printf() ?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?