Home About Us What We Do Who We Serve Contact Us Customer Login
What We Do
Reasoning Solutions
Discovery Mapping Analytics
Reliability Inspection Service
Security Inspection Services
Inspected by Reasoning
using Reasoning Services
 
 
Reliability Inspection Service

“Estimates of the economic costs of faulty software in the U.S. range in the tens of billions of dollars per year and have been estimated to represent approximately just under 1 percent of the nation’s gross domestic product (GDP).”

— May 2002 NIST Report, “The Economic Impacts of Inadequate Infrastructure for Software Testing”

For software development organizations coding in Java, C, and C++, Reasoning has a long track record of cutting costs and increasing predictability about application uptime and reliability. Reasoning can uncover a range of implementation defects that cause abnormal behavior or crashes and data corruption in production applications. Once identified and reported, these defects can be corrected before they cause problems.

Reliability Inspection Services
Reasoning’s Reliability Inspection Service focuses on identifying Java, C, and C++ software defects that cause crashes, corrupt data, and create unexpected behavior—all of which are potentially application stoppers. The Reasoning solution seamlessly reviews the entire available code base, pinpoints defects that reduce reliability and identifies the areas of highest risk.

Reasoning delivers defect data reports that make defect identification, analysis, and repair easy to accomplish. The reports serve as detailed roadmaps that clearly list the class and location of defects, the conditions under which they will happen, and a full description of defects down to the code fragment.

Companion defect metric reports, designed for managers, compare the organization’s code quality to industry averages, identify areas of code with the highest risk, and measure code quality and trends.

Defect Classes Found
Defects are reported in these broad classes for Java, C and C++:

Resource leaks –– Java file descriptor, socket handle, and database resource leaks are critical security-related defects that can be potentially exploited for the purpose of denial-of-service attacks, and can also cause applications to exhibit unreliable behavior or sudden failure.


Memory leaks
–– Memory leak refers to the loss of available memory space that occurs when dynamic data is no longer used, but is never de-allocated. Each time the leak occurs, the application drains the available memory pool. On some systems, memory may be allocated from a global pool, in which case the loss of available memory may affect the entire system, not just the application that caused it. Eventually, the performance degradation may lead to a fatal out-of-memory condition.


NULL pointer dereferences –– Occur when a member of a null variable is accessed; they can cause issues from resource leaks to application failure.


Out of bounds array access defects
–– Occur when an array index expression is not within the upper and lower bounds of the array; they can result in data corruption and application failure.


Uninitialized variable
–– With this defect, local and dynamic variables are not explicitly initialized prior to use. Usage of uninitialized variables can cause unpredictable results in the program, because the value of the variable is essentially random.


Dangling pointer
–– A dangling pointer refers to a defect in which a pointer is dereferenced after the memory that it points to has been deallocated. This defect can cause application crashes, unpredictable behavior and data corruption.


Bad deallocation
–– Bad deallocation uses an inappropriate memory release operation for deallocating memory, or to the deallocation of memory that was never explicitly allocated. Depending on the compiler and the specific operation, the impact of this defect can range from an application crash, to unexpected results, a memory leak, or memory corruption.


String comparison defects
–– In which two Java string objects are compared using either the "= =" or "!=" operators, instead of the String comparison methods available on the String object. If Strings are not properly compared, the software program will not execute as designed. What is especially important to note about these defects is that there is often no indication that a problem exists


Learn More
See Reasoning Resources and Downloads for:
• White Papers on Automated Software Inspection for Java and for C/C++
• Reliability Inspection Reports for Apache, Linux, MySQL and Tomcat


 

Contact Us

2006© Reasoning, LLC All rights reserved