Adv Debugging - My Program Worked Yesterday, but Not Today (WYNOT) by Andreas Zellar

Brief Notes of my understanding of on Delta Debugging as discussed in “Worked Yesterday, NOt Today" by Andreas Zeller 
Note:  To understand the basic premise and constraints/approaches of Delta-Debugging referred to the pdf link to:

1. Analyse the tables/graphs carefully. (80% of the understanding comes from the example tables/graphs)
2. Connect the WYNOT talk with Andreas Zellar's podcast on Software Engineering Radio.

Problem: Yesterday's code works but Today's code doesn't. How do we find the change(s) which induces the test-case failure.
Context: Looking through the CVS history we find that N changes have been added since Yesterday.

Alternative: Normally we would need run the debugger to reproduce the failure and then try to collect information which induces it.  But this requires a programmer to interactively query the program state using a debugger.
Can the debugging be automated without needing the programmer?

Strategy: Delta Debugging using a test-case to reproduce the failure.
Data Method:
Using the Scientific Method we can first try to reduce the Input Data in a binary search mechanism to isolate the minimum data which causes the failure.
Code Method:

1. Simple Method: When failure is caused by a single change. We can try to isolate the change which causes the failure by doing a binary search through the change history. If there are N changes between Y(esterday) and T(oday) we test 'k/2'th change where 1 <= k <= N. We go on partitioning until we find a failure-free change. The latest failing change is the culprit. Complexity of this binary search is O (log N)
2. Complex Method: When failure is caused by a combination of changes. Unfortunately it's Not always possible to use the Simple Method in the case when combination of changes cause the failure. In such a situation we need to identify at least 2 (or more) changes which together cause the failure. 

• Divide the change history into N changes
• Group N changes into say 4 units i.e. N = N/4 * 4
• Generate combinations with different units.
• Test combinations for the failure. 
• Prune any units which don't participate in the failure at all.
• Recursive above steps by sub-dividing the units above (quarters into octets and so on) until we finally we end up with minimal changes that reproduce the failure.

Proposed Plans to Reduce to Reduce Computation and Avoid Inconsistent Configurations :
a) Group related changes - changes on common date/file/variable are more likely to be related. Group them into a single unit to avoid dependency across units.
b) Prune configurations when they're obvious dead-ends e.g. Where change dependency is chained all the way (Today) 10->9->8->7->6->5->4->3->2->1 (Yesterday)
c) Exclude changed code which is never executed.

See Also:
Pdf: "WYNOT - Worked Yesterday, NOt Today"
Andreas Zeller
Podcast on Software Engineering Radio
Delta Debugging

Debugging with GDB's Cheat-Sheet of Commonly Used Options

Gdb:
Compiling a program for debugging:
    g++ -ggdb -O0 hello.cpp   # 
    g++ -g3 -O0 hello.cpp       # -g3 compiles debugging info for preprocessor macros and no optimization

Running a program under the debugger without arguments
$> gdb myProgram

Setting the program arguments:
   a)  $> gdb --args myProgram  10 20 30 40
   b)  (gdb) start 10 20 30 40  # sets temporary breakpoint at main() and calls run.
   c)  (gdb) file myProgram
        (gdb) run 10 20 30 40
   d)   (gdb)  set args 10 20 30 40
         (gdb) show args
        (gdb) run
    e) $> gdb myProgram core
    f) $> gdb -tui myProgram core  # start vim/emacs ide for debug session

Howto Debug a Core-Dump/Crash-Dump for a stripped binary from a production machine

Core dump Analysis:
core(5)– (Linux Programmer's Manual – File Formats)
Core Dump (Wikipedia)
Memory dump (Wikipedia)
CallStack (Wikipedia),
Enabling core dumps in embedded systems,


Dr Dobbs - Postmortem Debugging
Dr Dobbs - Post-Mortem Debugging Revisited

Stackoverflow article (with comments) on core dump analysis on Solaris,
Backtrace commands in GDB documentation
Howto generate a Backtrace for Bug Reporting by Testers (from Gentoo doc)

Stack buffer overflow (Wikipedia)

Segmentation fault (SIG_SEGV, SIG_BUS)
A FAQ: User contributed answers regarding the definition of a segmentation fault,
A "null pointer" explained,
Answer to: NULL is guaranteed to be 0, but the null pointer is not?
Resolving crashes and segmentation faults,
What is the difference between a segmentation fault and a stack overflow?

Windows:
Crash dump analysis website


Books:
Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems (by David J. Agans)
Software Exorcism: A Handbook for Debugging and Optimizing Legacy Code (by Bill Blunden)
Debugging by Thinking : A Multidisciplinary Approach (by Robert C. Metzger)
Memory Dump Analysis Anthology, Volume 1  (by Dmitry Vostokov)

Steps towards Technical Mastery

How do you know if you've become a Master in your field?

Is there any method to learn things quickly in any field?
How do you avoid stagnation and mediocrity after becoming competent in your field?
How do you become a Master?

Take software for example: How do you become a Master in it?

These are exactly the questions which have been pushing me to seek answers.
Well now that I've got some kind of grip on this quest I'm able to give some of the answers.
Or at the very least point the way.

Short Answer: You'll know it when you get there!!
Long Answer: You'll see the Sign-Posts as you move towards achieving Mastery. Read on for the gory details.

Basic Template with Ingredients for a Technical Blog

A good Technical Blog Post follows the Law Of Retention: repetition helps Retention

Some Questions on your Blog Post:

• Is your blog a frequently used resource for yourself and your readers? 
• Does it grow as you learn more - addressing different levels of questions?
• Is it short and informative while being complete and self-contained? 

Is your blog addressing The Readers Perspective?

1. What's in it for a Reader?
2. Tell 'em what you're going to Tell 'em.
3. Tell 'em.
   
4. Tell 'em what you just told 'em.
   
5. Further info.