Go back to blog listing

How Static Analysis Identified the Root Cause of Intermittent Erratic System Behavior

ScreenShot320.jpgA leading power management company helps customers effectively manage electrical, hydraulic and mechanical power more efficiently, safely and sustainably. As you can imagine, the safety and reliability of the software driving their innovations is critical to their success. To continue releasing cutting-edge products to the market faster than competitors, the company wanted to accelerate time to market—but only if they could find a way to achieve this without any increased risk of faulty software. 

The Electronics group recognized that static analysis’ defect prevention and defect detection capabilities had helped many similar organizations achieve this same goal, so they proposed a static analysis “proof of concept” (POC) to confirm whether the technology could deliver value in their specific environment. As part of their evaluation criteria, they wanted to determine if any of the market-leading static analysis technologies could expose the root cause of one of the most troubling defects they had recently encountered.

As their Division Engineering Manager explained, “One of our safety-critical products was experiencing a highly intermittent bug that manifested itself under only a very specific combination of inputs. Once it hit the condition, it would overflow the stack and halt the processor. Thanks to our recovery mechanism, the system would resume normal operation about 50ms after halting. Our only clue that that something was wrong was that the system would return to the initial state briefly before resuming work. Over the course of several months, we tried several methods to identify the issue. Finally, we came across the stack overrun and its cause: the recursive call loop. Once we root-caused it, the fix was a one-line change which took less than five minutes.”

During the static analysis POC, several static analysis tools were run against a legacy source code version (with the problematic line of code) to determine if static analysis could have prevented this defect. Out of the various static analysis tools, Parasoft static analysis was the only one that zeroed in on this defect. Although the group was previously sold on the benefits that static analysis could provide in theory, this discovery gave them the specific evidence that they needed to select the best static analysis tool for their needs and move forward with the purchase.

Their Division Engineering Manager noted, “I won’t detail the exact amount of engineering time we put into addressing this problem, but by my calculations, we spent thousands of dollars’ worth of effort to find the source of the problem. If we’d had Parasoft during this time, we would have identified the issue quickly and easily without the need for a long root-cause process.”

In response to this discovery, the organization has initiated a defect prevention strategy that is being implemented across their safety-critical development projects. Static analysis on the engineers’ desktops allows them to prevent the root causes of multiple application failure types—rather than having to discover and remediate the resulting defects late in the SDLC or after release.

Static Analysis Tool Evaluation Guide

justice_scale.jpgIf you're starting to explore how static analysis can help your own organization prevent these types of defects, we invite you to read our Static Analysis Evaluation Guide: 6 Steps to Choosing a Static Code Analysis Tool Your Team Will Actually Use. 

You'll learn about a 6-step approach to selecting a tool that suits your current situation—and will grow with you as your needs evolve.

This guide doesn’t push any specific solutions, but offers solid advice to help you perform your evaluation.

Stay up to date