Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Debugging Step by Step: Influence Debugging

DZone's Guide to

Debugging Step by Step: Influence Debugging

· DevOps Zone ·
Free Resource

Is the concept of adopting a continuous everything model a daunting task for your fast moving business? Read this whitepaper to break down and understand one of the key pillars of this model in Continuous Governance: The Guardrails for Continuous Everything.

Influence debugging is another way of active debugging.

The clue of debugging is to reduce the number of execution steps/statements we should investigate to find the fault. Let’s assume you detect a failure during a program execution (or a test, as we can use interchangeably). Without applying an active debugging method, you should visit each execution step. However, it’s not necessary, since lots of statement cannot cause the failure. Why? Because only about 10% of the statements have any influence on the one you detect the failure. You couldn’t know which these statements are, only an analyzer can do it.

The solution is to limit the code or execution steps being investigated. The first step is to determine the influences. A variable assignment influences a statement if the variable is referenced in it. Example:


x = 1 influences print x, since x is referenced in print x. In the other example, y = 1 has no influence on print x. Influences can be direct and indirect ones. An example for indirect influence is when x = 1 influences z = x * g(z), and this latter influences print z, see the figure below.


We can check influences in the following way: if we delete a statement and this deletion may modify the assigned value or outcome of another statement, then there is an influence. On the contrary, if we can delete a statement without causing any value our outcome change in the target statement, then there is no influence between them. We can actually delete the statements with no influences on the variable with erroneous value without changing the outcome. In real life applications this is a real gain, most of the statements in an applications can be neglected. Consequently, this is an efficient active debugging method.

Jidebug is an influence debugger based on byte code instrumentation. During instrumentation it detects and stores the direct influences between two executed statements. Selecting a variable with erroneous value Jidebug computes the influence chains and displays them. You can go backward along influence chains until the faults have been reached. This is not the only possible root cause, the problem can be a faulty control (eg. if) statement, not in any chain. Even in this case there should be an assignment incorrectly influencing the subsequent element in the chain.

A significant advantage of influence debugging is to help find one of the trickiest bugs, called missing case error. This happens when some code is missing. Obviously we cannot set a breakpoint at a missing location. However, the influences may reveal the problem. Here is an example:


We can see that statement x = 1 erroneously influences print x since inserting the missing code, the original influence disappears. Thus investigating the wrong influence, you can realize that something should be missing.

Influence debugging is a key feature of Jidebug active debugger, try it now for free. 

Are you looking for greater insight into your software development value stream? Check out this whitepaper: DevOps Performance: The Importance of Measuring Throughput and Stability to see how CloudBees DevOptics can give you the visibility to improve your continuous delivery process.

Topics:

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}