Delta Debugging is an automatic and systematic technique that deals with isolation of the source of the failure — often the developer’s longest, most demotivating, and most repetitive activity when carried out manually. Read more…
Delta Debugging is an automatic and systematic technique that deals with isolation of the source of the failure — often the developer’s longest, most demotivating, and most repetitive activity when carried out manually. Read more…
On a casual read of their example, the failure condition was gcc crashing. I can’t see any way to extend this technique much beyond that.
How about an HTML page that crashes a web browser (their example)? What if the problem isn’t a single tag? Maybe things go bad when more than 10 images are loaded: this system would blame the 10th image tag, which is likely to cause more confusion than it saves.
What about a real world problem (non-trivial, non-console, runs and produces bad output)? If parts of the code are changed, how do you decide whether you have the “real” bug or another one caused by the testing? Is there a way to analyze artifacting produced by an image processing algorithm with less code than the original program (since the testing function must be debugged too)? IF it were possible to identify failure programmatically, I still vote for the heat death of the universe occurring before the process finishes.
This is a really cool idea, but I suspect that automatic debugging is going to require computers capable of automatic programming.
@pauls101:
Delta Debugging might not be the solution that will relieve us of *all* debugging chores, but it could be one helpful tool in a developers toolbox. It’s certainly not applicable to all possible problems, but I suppose there are many programs where it *can* find a possible location of the issue (and as it’s automated, you or some testing/support crew can run it in the background and then just look at the results; if the tool was right… Great!, if not, then you haven’t really lost anything… except some CPU cycles, which would’ve idled nyway…).
TDD would exploit all the problems in the article in a natural way!
Care to ellaborate? Or is it a hunch?
Sorry, I’m unable to explain a whole approach to software design & development (and elaborate a comparison with delta debugging) in the space of a comment.
Your statement implies that neither the GCC developers nor the Mozilla developers use TDD because otherwise these two bugs wouldn’t exist
As already has been mentioned there is no debugging techniqe which discovers all bugs. In my opinion delta debugging could be an useful supplemental tool for hunting bugs in certain cases.
<
developer’s longest, most demotivating, and most repetitive activity
>
A developer who sucks at debugging isn’t a very good developer.
Think about it. As a developer, your job is to keep a mental model of the application and its inputs/outputs/behavior. When it doesn’t behave correctly, you run your model in your head and isolate the areas that may be where the problem is…which is usually where you just were poking around.
You then look, and follow the incorrect behaviors backwards.
Why is this hard? I’ve debugged operating systems, really large programs, and small programs, and the only difference between them is scale. I’ve debugged programs that I’ve never seen the source.
It’s just no that hard.
Source level debuggers are great, but in the end, the most useful things when you debug are printfs (or the local equivalent), stack traces (for the initial crash), and asserts. Oh, and your brain.
Problems in big systems are harder to track down, because it takes a while to recreate the problem. But good logging and a basic understanding of what’s supposed to happen should be more than enough.
I guess that’s what separates the good from the average.
To me, debugging is fun, because it’s the easiest way to see how well I really understand what’s happening (or supposed to happen).
TDD would exploit all the problems in the article in a natural way!
Did you mean “remove all the problems”? In that case I think your statement is a really bold one. Test driven development is unlikely to find or remove every bug on its own, like with every other development or debugging methodology.
—
El Pseudonymo
No, I’m wrote problems and not bug in relation to what is written in the linked article. Things like:
“Think of a program that crashes every time you feed it the specific input file foo.txt. The programmer needs to know what’s wrong with foo.txt, and usually starts the boring mechanical process of leaving out different portions of it and blindly retrying the execution until the program runs successfully. Eventually this trial-and-error procedure allows the programmer to isolate the source of the failure.”
or:
“Delta Debugging can also be applied directly to the code. If a specific release or revision works flawlessly but a more recent one shows a specific misbehavior, the source code for the two revisions can be the starting point for an application of the Delta Debugging algorithm. With a procedure similar to the one presented before, Delta Debugging iteratively runs different combinations of the code modifications, until a single difference is highlighted as failure-inducing.”