Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > T&M
?
?
T&M??

Uncovering static analysis pitfalls

Posted: 16 Feb 2009 ?? ?Print Version ?Bookmark and Share

Keywords:tutorial? analysis static?

By Matthew Hayward
Coverity

Perhaps the most surprising thing about static analysis is not that it can detect memory leaks, buffer overflows, or incorrect pointer assignments at compile time, but rather that users of static analysis will often fail to fix such detected defects.

One of the most frequently misunderstood aspects of static analysis is that it is distinctly different from other bug finding techniques. Static analysis users are often aware of the advantages it provides in defect detection, while simultaneously failing to realize that a different approach must be taken for defect resolution.

Static analysis has never been "just another way" to detect defects, nor is it just a way to detect defects earlier in the development cycle than was previously possible. Static analysis testing reports defects in a different way than dynamic testing and user reported defects; these differences must be understood and appreciated to effectively improve software quality with any static analysis tool.

Root causes vs. symptoms
When a defective application misbehaves, the user experiences a variety of symptoms such as crashes and slow or incorrect response. Each of these misbehaviors is triggered by a root causesome piece of code, which performs incorrectly.

Much of software defect remediation is based on the observation of symptoms, followed by debugging to identify the root cause. Typically, defect tracking tools and processes tacitly assume that the symptoms of a defect are all a developer has to go on when fixing a bug. Indeed, it would be unusual for a user to file defect saying:

Report 1:
On line 145 of file.c, the array "description" is written to with an input buffer whose maximum length is 24, as can be seen from the test on line 143, however the size of the description array is only 16bytes, as you can see in header.h line 23.

Instead the user would be likely to file a defect that says something like:

Report 2:
Whenever I enter the description: "Longer than 16bytes." into the form, the program crashes.

Static analysis, however, reports issues in a manner of Report 1, not Report 2. It's easy to get excited about how much easier it will be to fix the underlying bug when given Report 1 than it would be to fix if given only Report 2, but consider for a momentis Report 1 universally better than Report 2?

In fact, Report 1 is missing something fairly critical as compared to Report 2: the impact that this defect has at runtime.

Static analysis tools detect root causes; they pinpoint the location and triggering conditions for a defect, but do not predict the symptoms that will be observed at runtime. Contrast this with a user reported defect, where it may take considerable effort to identify the root cause, but where the symptoms, and therefore the impact, will by crystal clear.

Static Analysis and The Software Developer

In my observation there are few cynical developers when it comes to static analysis. Absent of the concrete impact of a customer reported defect, many developers express substantial optimism that a statically reported defect will not occur in the field, with a plan to cross that bridge when they come to it.

It's all to common an anecdote that a user of static analysis spends significant time debugging a customer reported issue, only to find out later that the same issue was previously reported by their static analysis tools.

Sometimes I suspect that developers are not really optimistic, but rather that they are overworked, and as such, can't engage in speculative behavior (such as fixing statically detected defects), over fixing a customer reported issue.

In reality, for a development organization to reap the quality and productivity benefits of static analysis, management needs to support the effort by helping to ensure sufficient time is budgeted for the inspection and resolution of statically reported issues.

- Matthew Hayward is director of professional services for Coverity Inc.





Article Comments - Uncovering static analysis pitfalls
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top