Automated Debugging (6): simplifying problems - smiple testcase for complex bug repor

need some more time for each of the left chapters

1. Main points

* The aim of simplification is to create a simple test case from a problem report.
* Simplified test cases…
*** are easier to communicate
*** facilitate debugging
*** identify duplicate problem reports

* To simplify a test case, remove all irrelevant circumstances.
* A circumstance is irrelevant if the problem occurs regardless of whether the circumstance is present or not.
* To automate simplification, set up
*** an automated test
*** a strategy to determine the relevant circumstances

One such strategy is the ddmin delta debugging algorithm

ZW Comment: ddmin is a great idea, but seems to be not that general to be used in every scenarios
(in fact, my current thought is that its application domain is not that broad, anyway the simple failure-inducing input in the given example is not that common in practice).

Some more examples where ddmin might be useful:
* Simplified failure-inducing fuzz input:
* FLEX crashes on 2,121 or more non-newline characters
* NROFF crashes on “\D^J%0F” or “\302\n”
* CRTPLOT crashes on “t”

The algorithm complexity analysis is out of my expectation. As I thought, the space is 2^M (might be a good target for GA :-), but the author give an algorithm whose worst case is (|c| ^ 2 + 7 * c) / 2.

Hehe, I guess there might be some corner of this space is not covered by his method.

Need some more look.