Slashdot Mirror

← Back to Stories (view on slashdot.org)

New & Revolutionary Debugging Techniques?

Posted by CmdrTaco on from the something-to-think-about dept.

An anonymous reader writes "It seems that people are still using print statements to debug programs (Brian Kernighan does!). Besides the ol' traditional debugger, do you know any new debugger that has a revolutionary way to help us inspect the data? (don't answer it with ddd, or any other debugger that got fancy data display), what I mean is a new revolutionary way. I have only found one answer. It seems that Relative Debugging is quite neat and cool."

4 of 351 comments (clear)

  1. Another cool technique by Halo1 · · Score: 5, Informative

    Debugging backwards in time. See the Omniscient Debugger for an implementation in Java. Instead of re-executing the program a thousand times, each time setting breakpoints and watchpoints in different places to get nearer to the root cause of the problem, this debugger completely records all key events and lets you view the complete program state at any point in time.

    --
    Donate free food here
  2. Aspect-Oriented Programming can help by cpu_fusion · · Score: 5, Informative
    I've found that aspect-oriented programming using tools like AspectJ (for Java) can be a big help. There are aspect-oriented programming tools for many other languages.

    Basically, you can define an aspect to capture points in your program that are of particular note, and then do debug handling at those points. Aspect oriented programming allows you to break out that debug-handling logic into seperate modules, keeping your main sourcecode nice and clean.

    Aspect-oriented programming (AOP) has a lot of other uses too. I think in 5 years or so talking about AOP will be as commonplace as talking about OOP. They are orthogonal concepts.

    Cheers, Me

  3. Some ideas by AeiwiMaster · · Score: 5, Informative

    They might not be revolutionary, but the is a few ideas
    which can be just to reduce the number of bugs in a program.

    1) 100% unit test coverage of your programs.
    2) Statistical Debugging

    3) Valgrind

    4) The D programing Language
    with build in support for unit testing, contracts and class Invariants.

  4. With hardware you have no choice by Alan+Cox · · Score: 5, Informative

    Its all very well talking about elegance and planning in advance until you try and deal with hardware. No amount of zen contemplation of your code is going to tell you what a debugger does about how the hardware and its documentation relate.

    The neatest debugging tricks I've seen so far are those logging all inputs and returns from the OS level. Since you can replay them you can rerun the app to an earlier point and investigate - in effect you can run it backwards from a bug to see how it got there.