Please create an account to participate in the Slashdot moderation system


Forgot your password?
Programming IT Technology

How Would You Improve Today's Debugging Tools? 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?"
This discussion has been archived. No new comments can be posted.

How Would You Improve Today's Debugging Tools?

Comments Filter:
  • Perhaps.... (Score:5, Funny)

    by foxtrot ( 14140 ) on Wednesday January 08, 2003 @03:04PM (#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.... (Score:5, Informative)

      by Joseph Vigneau ( 514 ) on Wednesday January 08, 2003 @03:10PM (#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.... (Score:5, Interesting)

        by Titusdot Groan ( 468949 ) on Wednesday January 08, 2003 @03:41PM (#5041982) Journal
        I found that as I started using OO languages and techniques (Objective C and Java + MVC and Design Patterns) I almost stopped using debuggers. I almost always know exactly where the bug is as soon as I see the behaviour and can find it by inspection in a few seconds.

        This is also experienced based -- as I get older I use debuggers less and less but my code output has remained constant or improved (even though I don't put in all nighters any more :-)

        I'm finding it really hard to get excited by the fact that there is no effort being put into debuggers where as 10 years ago it would have been a big deal.

        Perhaps that's also part of the problem -- when I evaluate tools etc. I don't spend a lot of time looking at the debugger these days ...

        • Re:Perhaps.... (Score:4, Insightful)

          by John Wharfin ( 639610 ) on Wednesday January 08, 2003 @04:35PM (#5042506)
          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.
          • Re:Perhaps.... (Score:4, Informative)

            by giel ( 554962 ) on Wednesday January 08, 2003 @09:13PM (#5044119) Journal

            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.

      • Re:Perhaps.... (Score:4, Insightful)

        by Shamanin ( 561998 ) on Wednesday January 08, 2003 @03:47PM (#5042026)
        "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.
        • Re:Perhaps.... (Score:3, Insightful)

          by gorilla ( 36491 )
          Testing and debugging are two seperate activites, and it's important not to try to confuse them.

          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.

        • Re:Perhaps.... (Score:4, Interesting)

          by dubl-u ( 51156 ) <> on Wednesday January 08, 2003 @04:13PM (#5042292)
          Well, when you combine enough of your small functions/methods together into one big monolith of a program problems tend to surface. What then?

          Then you haven't written enough tests. Or you're trying to integrate too much at once.

          If you do test-first development [] and continuous integration [] (backed up with good black-box integration testing), then the number of bugs you get should be low. In my experience, that's circa one shipped bug per man-month.

          If I run all the tests frequently as I develop and check in often, I rarely need a debugger. If I break a test, I generally know exactly what the problem is.

          If I forget to run all the tests and check in, then the automated build box will send me email promptly, so it's still pretty easy to find the problem.

          It is essential, like an x-ray / CT-scan / ultrasound is to a surgeon.

          Note that the only time you see a surgeon is when something is pretty seriously wrong. Isn't it much better to make sure that things don't go so far wrong that a surgeon is necessary?
          • Re:Perhaps.... (Score:3, Interesting)

            by Shamanin ( 561998 )
            "Note that the only time you see a surgeon is when something is pretty seriously wrong. Isn't it much better to make sure that things don't go so far wrong that a surgeon is necessary?"

            I would call a bug a serious problem. I made no statement about abandoning unit and integration testing, only that the utility of a debugger is essential for the development process. And, to be precise, I should have said a radiologist rather than a surgeon since this would be a pre-screening before any manipulation is done to the body, I mean code.
    • by L. VeGas ( 580015 ) on Wednesday January 08, 2003 @03:11PM (#5041665) Homepage Journal
      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.... (Score:2, Insightful)

      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.
    • Write-time debugging (Score:3, Interesting)

      by JohnFluxx ( 413620 )
      How about instead of not using any debugging tools, you debug at write time?

      For a lot of code, the compilier should be able to work out the pre and post conditions of a function, and then just check that when you call that function you don't violate them.

      Also I'd like to be able to hover my mouse over a variable and see what range of values it could have. From here you can check that you never go outside the bounds of a variable, and so on.

      Obviously you can never get it to work on all cases due to the halting problem, but it will work with a lot of code - and on confusing code you can manually add the special comments for the post and pre conditions - a good idea anyway for complex code.

  • 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!
    • 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.
  • by stratjakt ( 596332 ) on Wednesday January 08, 2003 @03:06PM (#5041616) Journal
    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.
  • by koali ( 175176 ) on Wednesday January 08, 2003 @03:07PM (#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.
    • by sdjunky ( 586961 ) on Wednesday January 08, 2003 @03:13PM (#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.

      • by Anonvmous Coward ( 589068 ) on Wednesday January 08, 2003 @03:24PM (#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.

        • by vadim_t ( 324782 ) on Wednesday January 08, 2003 @03:38PM (#5041960) Homepage
          Ah, but here's the problem. People fail to understand the purpose of VB far too often.

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

          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.
          • by dubl-u ( 51156 ) <> on Wednesday January 08, 2003 @04:25PM (#5042411)
            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.

            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 .NET languages seem to be minor syntax variations on Java, maybe that's not too surprising.)
            • 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...
      • 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.
    • 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.

    • by rvaniwaa ( 136502 ) on Wednesday January 08, 2003 @03:20PM (#5041760) Homepage
      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)


    • or at least be able to view a variable's history

      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.

  • by trexl ( 16434 )
    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.
  • by jdavidb ( 449077 ) on Wednesday January 08, 2003 @03:08PM (#5041628) Homepage Journal

    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.

  • Forget the Debugger (Score:3, Interesting)

    by sohp ( 22984 ) <{snewton} {at} {}> on Wednesday January 08, 2003 @03:08PM (#5041630) Homepage
    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.
    • by DoseKapital ( 639545 ) on Wednesday January 08, 2003 @03:18PM (#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?

    • I fully agree that debuggers are useless. And I also agree that writing tests is important. But I think you forgot the most important development techniques obviating the need for debuggers:
      • Use assertions and error checks liberally throughout your code--it documents better than anything else what your code is expecting. Write assertions for input arguments, outputs, class invariants, loop invariants, etc. Test cases are much less useful without assertions; with good assertions throughout the code, testing becomes much, much easier. Conditionalize costly assertions to compile them out in cases where you really have no other choice.
      • Integrate visualization code into your code--it helps both you and future developers figure out what's going on.
      • Use languages with strong (dynamic or static) type checking and with few or non "undefined effects".

      Java, C#, OCAML, Scheme, and Python fall into this category. Perl to some degree. You can write solid C++ code if you try, but if you use STL or most of the common C++ libraries, you can't--you'll end up in debugger hell.

      For the last ten years, I basically only use debuggers to get me stack back traces in languages like C++ that don't print them by default. In Java, I haven't touched any debugger (does it even ship with the JDK?).

  • by UncleFluffy ( 164860 ) on Wednesday January 08, 2003 @03:08PM (#5041633)
    fprintf(logfile, ...

    and the mighty grep
  • by Greenisus ( 262784 ) <[michael] [at] []> on Wednesday January 08, 2003 @03:09PM (#5041640) Homepage
    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.
    • Doesn't work when someone clobbers your memory.

      But it's kind of a neat idea. It would certainly be expensive, though.
      • In that case, it would also be nice to be able to test other system conditions: such as memory allocated/remaining. Then when you're about to run out you can pause and get a history of where all the allocations are coming from.
    • I have found that my reliance on debuggers has waned over my years of programming. I find that personally there are two reasons this has happened for me. First, I used to do mainly procedural programming and an integrated debugger was really helpful there. Now most of my programming is OO in C++ and Java. IMHO current debuggers are still designed to support procedural code. The errors that your create in OO code are in my experience more subtle and often times harder to detect making the debuggers almost useless. Secondly my experience of over 25 years of doing this kind of thing has created more of an intuitive sense of my own internal debugger. A few well placed 'cout' or 'println' statements often tracks the problem down. Diagramming out the stack frames on paper seems to help and actually provide a quicker solution than the debugger utilities. I have to really think about what is going on.

  • by exp(pi*sqrt(163)) ( 613870 ) on Wednesday January 08, 2003 @03:09PM (#5041643) Journal
    • 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.
    • Reversable debugger (Score:3, Interesting)

      by mahlen ( 6997 )
      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).


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

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

      This is obviously not always possible as many functions (squaring a number, sin of a number, ...) are not reversible

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

    • You might want to add execution history to the list.
      A stack trace gives you the current calls but what were the previous 5 calls made?
      An execution history would tell you what the last N calls were and in what order they occured.
      It would be easy to implement as a series of stack snapshots.
    • by Jamie Zawinski ( 775 ) <> on Wednesday January 08, 2003 @07:58PM (#5043745) Homepage

      Yes, I could really use a debugger that runs backward for a problem I'm having recently. I wrote about it here [] last month:

      Shaver pointed out
      this message []. Apparently Michael Chastain wrote the very program I'm looking for [], back in 1995. Nobody cared, the kernel APIs kept changing underneath it, and it died on the vine.

      [...] The replayer is the cool part. It takes control whenever the target process executes a system call, annuls the original system call, and overwrites the target process registers and address space with the values that I want to be in there.

      [...] If I put memory-access rule checking in at replay time, I can do better than e-fence, on stock binaries with no recompilation. Hell, I can do better than Purify on stock binaries and without tangling with their object-code-insertion patents.

      I have enough information available in the proxy ptrace filter to implement PTRACE_SINGLESTEP_BACKWARDS. How would you like to have that capability in gdb? "Execute backwards until this data watchpoint changes." Imagine a graphical debugger with a scrollbar for time, where the top is "beginning of execution" and the bottom is "end of execution."

      Yay progress.

      Ok, the rest of his message [] reads as a ``why does my genius go unappreciated'' whine, but still, I want this program! The code is still available, but I'm sure not feeling motivated to try and port it to run on a modern kernel (it doesn't even support ELF binaries...)

      It looks like after this message was sent to the linux-kernel list in 1999, there was a whole lot of talk, then three years of zilch. I mailed to ask if any progress was ever made. The answer was no: nobody ever made it work on modern systems.

  • by rvaniwaa ( 136502 ) on Wednesday January 08, 2003 @03:09PM (#5041647) Homepage
    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...
    • by EvlG ( 24576 ) on Wednesday January 08, 2003 @04:21PM (#5042375)
      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?
  • by reimero ( 194707 ) on Wednesday January 08, 2003 @03:09PM (#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.
  • by kvn299 ( 472563 )
    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.
  • by mumblestheclown ( 569987 ) on Wednesday January 08, 2003 @03:11PM (#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).
    • 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.
      • I second that, or rather, third that.

        I happen to be involved in some VB6/VB.NET development of substantial applications, and I havent found anything that matches it closely in terms of functionality or ease of use.

        If I have ever have to script something big with WSH/VBA it is so noticable how much the debugger helps.
    • 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)).

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

  • make sure the debugger checks for GPL violations.


  • by dilute ( 74234 ) on Wednesday January 08, 2003 @03:12PM (#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.
    • Strategically embedded print statements - the time-honored way to find bugs.

      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.

  • println debugging (Score:4, Interesting)

    by kisrael ( 134664 ) on Wednesday January 08, 2003 @03:12PM (#5041675) Homepage
    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.
  • 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 [].
  • "How Would You Improve Today's Debugging Tools?"

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

    • "How Would You Improve Today's Debugging Tools?"
      Make them work better at debugging. What a pointless story/question this is."

      "What is the cause of most plane crashes?"

      "What a dumb question. It's gravity!"
  • Is miles in advance of earlier versions of debuggers. Change code at runtime, you sexy beast.
  • by Shaleh ( 1050 ) <shaleh AT speakeasy DOT net> on Wednesday January 08, 2003 @03:13PM (#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.
  • 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.
  • 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 :-)

  • by doi ( 584455 ) on Wednesday January 08, 2003 @03:15PM (#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.

    • by MarcoAtWork ( 28889 ) on Wednesday January 08, 2003 @03:34PM (#5041922)
      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?
  • 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.

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

  • by Viking Coder ( 102287 ) on Wednesday January 08, 2003 @03:17PM (#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.
  • by Azar ( 56604 ) on Wednesday January 08, 2003 @03:18PM (#5041733) Homepage
    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 (Score:5, Interesting)

    by Rary ( 566291 ) on Wednesday January 08, 2003 @03:18PM (#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.

  • by Anonvmous Coward ( 589068 ) on Wednesday January 08, 2003 @03:18PM (#5041736)
    ... about Debugging Tools. He felt that engineers should just learn to write software without bugs in it.
  • 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.

  • 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.
  • 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?"
  • There's an article in the latest issue of Embedded Systems Programming [] about using visualization tools for debugging. Well worth reading.

  • Debugging (Score:3, Insightful)

    by bytesmythe ( 58644 ) <.bytesmythe. .at.> on Wednesday January 08, 2003 @03:21PM (#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.
  • More is bad (Score:5, Insightful)

    by FortKnox ( 169099 ) on Wednesday January 08, 2003 @03:21PM (#5041777) Homepage Journal
    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.
  • by RelentlessWeevilHowl ( 451367 ) <weevilhowl&celia,serv,net> on Wednesday January 08, 2003 @03:22PM (#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?
  • 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.
  • by gUmbi ( 95629 )
    Exception stack traces are a godsend.

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

  • by theonetruekeebler ( 60888 ) on Wednesday January 08, 2003 @03:24PM (#5041803) Homepage Journal
    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.

  • One feature I really liked, that exists in a few places such as VC++ and edebug (for emacs), is the ability to jump around in the code and set values at runtime. You can do a lot with these two features, from running the same code over and over at runtime with different values, to skipping over a part of the code you consider problematic and seeing if it helps.
  • one word... (Score:4, Funny)

    by outsider007 ( 115534 ) on Wednesday January 08, 2003 @03:30PM (#5041878)
  • by grmoc ( 57943 ) on Wednesday January 08, 2003 @04:04PM (#5042203)

    I just need the "why" command..
  • by defile ( 1059 ) on Wednesday January 08, 2003 @04:19PM (#5042346) Homepage Journal

    But I only use debuggers for two purposes.

    Purpose 1. Segmentation Fault (core dumped). Uhm, now where did that happen? Whip out gdb, find the line that generated SIGSEGV, and it's usually obvious how it happened. If not, I have it print out a stack backtrace. If I really can't figure it out then, a 5 minute walk around the block and I'll have figured it out as soon as I sit back down.

    When writing in high level languages, I'm finding that debuggers are wholly unnecessary. In fact, I can't remember the last time I spent more than 20 minutes trying to track down a bug. *shrug*

    It'd be nice if debuggers solved my problems automatically, but I'm really finding that I don't need them. I might even go so far as saying use of debuggers encourages dependency on debuggers, which in turn discourages thinking about the program itself. Not saying that EVERYONE does this, just that some of the best work gets done remarkably well even without debuggers.

    The Linux kernel, for example, was largely developed without the aid of a debugger, and the core developers seem to eschew them. Here's a good thread [] on why the developers don't want to include a debugger.

    Purpose 2. On the other hand, debuggers are remarkably good at helping you break program code. With having almost no experience using gdb, I was able to break the license key check on Intel's C Compiler in about an hour. I was amazed at how easy it was to attach a debugger to the compiler and skip the subroutine that performed the license key check. With no debugging symbols to work with. Disassemblers rule. It took another 10 minutes to turn this into a script that could be distributed as a wrapper for icc (called xicc), so all you had to do was set CC=xicc in the Makefile.

    Sure I could have used LD_PRELOAD so that time() always returned a date within the trial period, but breaking program code with a debugger is just so gosh darn fun.

  • GDB the millstone (Score:3, Interesting)

    by DrXym ( 126579 ) on Wednesday January 08, 2003 @04:25PM (#5042414)
    I don't know about others but I find it an immense pain in the backside to debug anything on Linux. The reason is GDB which has to be the biggest hinderance to development on Linux. Arcane, slow and unintuitive would be words best used to describe it. You could grow a beard while waiting for a backtrace when debugging a stack overflow in an app like Mozilla. I've seen GDB page my system to death before now, such must its memory requirements must be for some operations.

    Even front end tools are little help. DDD is much better than the cli but it still suffers the same performance faults as GDB and introduces some fun issues of its own. Even a 'commercial' tool such as Project Builder on Mac OS X groans to a halt with GDB running underneath and has some very odd concepts concerning when breakpoints are hit or not.

    All this would be understandable if Win32 were the same but it isn't. Debugging on Win32 is a snap - just in time debugging, compile in time debugging, a debugger that works, integration with the editor and more. It is sad to say that if asked and irrespective of open / closed source issues, which OS were the better for development I would say Windows. In fact, if I'm faced with a bug in Mozilla, I'd rather fire up Windows and replicate the problem there than wade through the shit that GDB throws in my face.

    Die GDB! Linux really needs a decent debugger and all the mod cons that Windows developers have benefited from in the past decade.

  • by Lumpish Scholar ( 17107 ) on Wednesday January 08, 2003 @04:29PM (#5042453) Homepage Journal
    Recently I was given some Java code and asked to port it to C++. At the time, my knowledge of Java was pretty much at the "Where is the bathroom, please?" level. In particular, I could see where the reflection package was being used, but not how the program went from one particular bit of client code to another. I loaded the code into the debugger, started the program, set a few breakpoints at the really puzzling parts, and ran through it a few times. At that point, the student achieved enlightenment.

    As I've gotten more skilled at software development, I've become better able to read a bunch of code and analyze it ... and become more likely to run the darned thing and see what it really does. Sometimes, in this job, inspection is theory, and debugging and testing are experimentation.

    An MIT animal physiologist is said to have told his students, "The animal is always right. When in doubt, ask the animal." Ask the code; the code is always right. (It may be right in knowing what the bug is, but sometimes that's what you need to ask.)

    P.S.: I've learned more Java since then. Running some programs through its debugger was one good way to help learn it.
  • Savestates. (Score:3, Interesting)

    by RyanFenton ( 230700 ) on Wednesday January 08, 2003 @05:11PM (#5042849)

    If you've ever followed the popular system computer simulators known as emulators, you've likely seen savestates. It's effectively saving all the variables of a system en bulk, to be leaded back again later so another approach might be taken. They have been very useful to emulator developers who often need to return to an exact point where a virtual machine breaks down, without having to re-run to a certain point.

    It would be nice if debuggers could automate the process of saving the state of functions (and everything they immediately touch), so you could go "back in time" rather than need to restart a program in order to return to a non-bugged state. On small programs, it would also be very convenient to be able to save the state of the entire program.

    Possible extentions of this idea would be a breakpoint-like auto-savestate at a certain line, and a "step back" feature to be able to rollback one line.

    Of course, there would be many possible complications involved in using savestates - but I believe the potential dangers are far outweighed by the opportunities for quicker and more comprehensive testing and code-observation.

    Ryan Fenton
  • Superdebuggers (Score:5, Interesting)

    by jimfrost ( 58153 ) <> on Wednesday January 08, 2003 @05:23PM (#5042918) Homepage
    Well, it just so happens that there have been a few debuggers much more functional than the likes of Visual Studio.

    I used to work for a company called Saber, who later changed their name to Centerline. We produced a product called Saber-C (and later Saber-C++, and the products were renamed CodeCenter and ObjectCenter).

    This product was a C/C++ superdebugger. It started out as a C interpreter developed at Harvard. Now, an interpretive environment allowed a lot of neat features: You could tell whether or not variables had been initialized at reference time, you had complete stack and context information, it was pretty easy to unload and reload code in source modules (dynamic reloading). You also got dynamic type checking, which caught errors in downcasting (for instance). And everyone's favorite, array bounds checking.

    With this tool debugging C code often meant: Loading the code, running your test case, and seeing where the debugger complained. The first time you ran your code through it was a humbling experience ... almost all production code has serious (but normally benign) errors.

    Unfortunately the tool didn't scale well because it took time to load the interpreted code into the debugger and the heap and runtime requirements of interpreters stressed machines of the time (this was when Sun3s were common, and 3/50s couldn't even have more than 4MB memory).

    I think it was 1990 when we released version 3, whose big new feature was object code debugging (it's not really that easy to have object code debugging as well as interpretive code, although we could certainly have implemented it more easily than we did). We of course maintained the ability to dynamically reload code fragments, so you could do a "make", reload the affected modules, and be on your way in a few seconds. This sure beat the several minute wait you normally had with the linker and debugger restart. But what you lost was some of the runtime checks -- including most of what made the product interesting. Still, the ability to have superdebugger capabilities on some code and still scale to large programs was very valuable.

    About a year, maybe two years later we got visited by the people who eventually started Purify. They had a neat approach where they'd get most of the benefit of our tool, but in object code, by disassembling the object code, adding extra code to perform checks, and putting it back together. This would give about 80% of the functionality of our debugger but with much lower runtime costs and work even if you didn't have source code.

    We ended up re-implementing this functionality such that we had a Purify competitor (and getting sued, and losing, even though Sun later patented the same technique we used).[1] Integrating it into the debugger allowed you to fine-tune the debugging capability you wanted on a module-by-module basis. This was a superb tool.

    Now, what are the raw capabilities that made this stuff really neat?

    1. Incremental reload of modules. That removes the debugger restart cost (symbol loading is a huge time sink).
    2. Supply worst-case scenarios for code. In our tool, we'd initialize heap and stack memory to 0xbfbfbfbf patterns, which tended to trigger bugs in code that had intitialization errors.
    3. Track heap allocations. Knowing who allocated something is remarkably valuable, particularly for tracking down memory leaks.
    4. Augment the code with error checks that are sensible for the source language. For instance, we knew the type that was assigned to memory so we used that to detect all manner of type mismatches.
    5. Augment the code with bounds checking for arrays. The bounds checkers worked with the heap system, which of course tracked the size of all allocations. This caught a lot of off-by-one errors.

    The tool also provided two additional interesting features. One was called "action points". Since we had a C interpreter in the product it was no big deal to allow you to type C code into it and run it at arbitrary times. We'd allow you to attach any code you wanted to any line in the program or to just type code at the debug prompt and it would run in the current scope. This was useful for things like adding print statements without recompiling, for instance, and for adding assertions, and many other things.

    The other feature was a graphical heap inspector. All this did was display structures as tables of their internal values and allow traversal of references to other structures, which would be displayed (including links between the structures). This made the shape of data a LOT easier to determine.

    Several people talked about adding reverse execution. That was actually done for Java by a tools company back in 1996 (maybe 1997). It didn't always work, but it was pretty neat. The problem is that the recording code was pretty expensive and there's a limit to people's patience and what they'll spend on hardware (although I grant that hardware is a lot less of an issue today than it was even in 1997, to say nothing of 1989). Anyway this feature is a lot less interesting if your debugger can find errors at the point they occur.

    Anyway, back in 1995 when I started to work with Visual-C++ on a regular basis I was appalled by what Microsoft was calling a "state of the art" debugger. Feh! It was 1985 technology with a pretty face. It really has not improved much since then either, although they do at least have a pessimistic heap allocator now. With their ability to hook in with the compiler they could do a phenomenal job with heap allocation tracking and instrumentation of code with error checks but they don't bother (because, I suppose, they make their money even without it).

    Now, using a language with runtime error checking built in - such as Java, C#, or Visual Basic, seriously undermines the amount of effort you have to put into the debugger. Still, I'd like to see a lot better heap debugging features built into compilers and runtime environments.

    Hope this gives people some ideas, and that they lead to tools I can use.

    [1] One thing that could be done to avoid the Purify patents would be to have the compiler emit the instrumentation. For the OSS world, where you always have the source code, that is eminently practical. Furthermore you can get all the benefits of an interpreter but at higher performance. A big problem with Purify's technology, and the technology we came up with, was that you're doing a lot of heuristics during code inspection. It's easy to miss code or misinterpret code, and of course the code inspector is VERY architecture and compiler dependent. What I would like to see is a gcc/glibc/gdb combination where the compiler, libraries, and debugger all worked together. That wasn't possible back when the vendor controlled the compiler and you didn't have access to library source. Today it is, at least for the OSS world.

  • by ry4an ( 1568 ) <ry4an-slashdot AT ry4an DOT org> on Wednesday January 08, 2003 @05:41PM (#5043048) Homepage
    In The Practice of Programming Brian W. Kernigan and rob pike said:

    As personal choice, we tend not to use debuggers beyond getting a
    stack trace or the value of a variable or two. One reason is that it
    is easy to get lost in details of complicated data structures and
    control flow; we find stepping through a program less productive
    than thinking harder and adding output statements and self-checking
    code at critical places. Clicking over statements takes longer than
    scanning the output of judiciously-placed displays. It takes less
    time to decide where to put print statements than to single-step to
    the critical section of code, even assuming we know where that
    is. More important, debugging statements stay with the program;
    debugging sessions are transient.
  • by Snafoo ( 38566 ) on Wednesday January 08, 2003 @07:48PM (#5043661) Homepage
    It runs during installation. To activate it, click 'I do not agree' when some incomprehensible gobbledegook called a 'EULA' is shown. A EULA is a kind of bug. Unless you refuse to accept, it will bug you again and again. Don't confuse bugs with viruses, however: Microsoft's debugger can't handle viral licenses, which is why they don't like the GPL. Once activated, the powerful EULA non-acceptance debugging option leaves your system bug-free.

  • by ThaReetLad ( 538112 ) <sneaky@blueRABBI ... minus herbivore> on Thursday January 09, 2003 @05:20AM (#5045819) Journal
    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++.

This process can check if this value is zero, and if it is, it does something child-like. -- Forbes Burkowski, CS 454, University of Washington