Note on Software Debugging Lecture 4

Software Debugging Banner

I’m taking a class from Udacity about Software Debugging. This is my week 4 of study.

One principle that you have to keep all the time is “Cause-to-Effect”. Sherlock Holmes would be the greatest debugger if he lived in our computer age. He masters in reasoning skill, so that with a little scratch on a Dr. Watson’s shoe, he could entail back to Dr. Watson ran back to the house.

Debugging with “Cause-to-Effect” principle in mind leads to deduce from bulky erroneous code into few several error causing relevant lines. We recursively look code backward and keep asking “Who did it?” over and over. Then, we will eventually reach the root of error, the defect. Pex is an automated tool for checking corner cases. It injects possibly causing error inputs and show a result for each input. Double checking both by hands and by tools will give much confident that code is bug-free (just confident).

The line between root and cause is dependency. And, in programming, there are 2 types of dependencies:

  1. Data dependency
  2. Control dependency

These two are a compliment of each other. Control dependency makes data dependency events happen.

There is another fancy term for dependency in program debugging called “Splice”.

  1. Backward splice – what this code depends on
  2. Forward splice – what this code will affect to

One of tricks that eases debugging is “Dynamic slice”. Instead of looking into actual code, we look into actual execution. We usually call a record of execution as “Trace”. By considering only code that was executed, we can narrow down to parts that is relevant to make an error scenario. Then, We can track down from effect to cause with lesser effort.

An error may be influenced by many possible causes. We may spend much time on negative causes instead of fixing the actual cause. Therefore, it is by common sense that we go for the most likely origin of error. The lecturer gave a criteria on selecting which to go for first.

  1. Infections
  2. Causes
  3. Code Smell
  4. Bug History
  5. Last Changes
  6. Anomalies

We can use “Delta Debugging” concept from the previous lecture to find the cause of an error. We inject value which causes an error to disappear. Then, we found root-to-cause chain of the error. But to be “Delta”, it has to be minimum change. It is one tick that vanishes the disaster.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s