PART 4: Unified and Generative Debugging
A Periodic Table of Software Defects
The author discovered rules that make it possible to devise a memory dump and software trace analysis equivalent of the Periodic Table of Elements in Chemistry. It allows prediction of abnormal software behavior and structural defects and what patterns to look for after deploying software and collecting its artifacts.
Analysis, Architectural, Design, Implementation and Usage Debugging Patterns
We now start unifying software behavior analysis patterns with debugging architecture, design, implementation and usage. This is analogous to software construction where a problem analysis leads to various software engineering phases. The important difference here is the addition of debugging usage patterns. Let's look at an example:
• Analysis Patterns
Shared Buffer Overwrite (Volume 5, page 120)
• Architectural Patterns
Debug Event Subscription/Notification
• Design Patterns
Punctuated Execution
• Implementation Patterns
Breakpoint (software and hardware)
• Usage Patterns
Kernel vs. user space breakpoints
To differentiate this systematic approach from the various published ad hoc debugging patterns we call it Unified Debugging Pattern Language. ADI parts can also correspond to various DebugWare15 patterns (Volume 2, page 391, and Volume 4, page 307).
Generative Debugging
Followed by our search for a periodic table of software defects (page 171) we came up with a novel approach called Generative Debugging partially borrowed from principles and parameters16 generative linguistics framework. For debugging and post-construction software problem solving17 purposes we have Behavioral Principles and Structural Parameters. The parameters allow us to describe existing and even generate new software defects (We're also considering Structural Principles and Behavioral Parameters but whether this is fruitful needs to be explored and seen). We may also consider the name “generative debugging” as a “naming” counterpart to software construction problem solving called generative programming18. So the former could also be used to generate problem solutions faster in automatic fashion. Both, in the future, may be combined into a unified generative software problem solving.
As a first example, consider an application functional hang with a thread blocked by a pending I/O request packet (IRP). It is composed from general behavioral principle of blocked (or unresponsive) activity and structural parameters including Thread and IRP.
Metadefect Template Library
To model software behavior at application and system levels, test generative debugging (page 173) scenarios and construct software defects using metaprogramming19 we started working on MdTL (Metadefect Template Library). It consists of C++ templates for structural and behavioral patterns. The simplest examples include Threads<Spike> and Spike<Thread>. The template classes can be more complex, of course, utilizing the full power of C++, STL, and existing libraries like Boost. The unique and novel feature of this library is the inclusion of dual classes of behaviour such as Leak<>, Deadlock<>, Overflow<>, Residue<>, Exception<>, Contention<>, etc. parameterized by various structural memory classes like Process<>, Thread<>, Heap<>, Stack<>, Region<>, Buffer<>, etc. MdTL also includes classes to model software tracing and this can be used for simultaneous software trace and memory dump analysis. We also plan to extend this metaprogramming approach in the future to model malware analysis patterns by introducing Metamalware Template Library (MmTL).
15 http://www.dumpanalysis.org/blog/index.php/debugware-patterns/
16 http://en.wikipedia.org/wiki/Principles_and_Parameters
17 http://www.dumpanalysis.com/files/Pattern-Driven-Software-Problem-Solving-Introduction.pdf
18 http://en.wikipedia.org/wiki/Automatic_programming#Generative_programming