This topic covers how to analyze the bugs reported by Flow Analysis
In this section:
This topic explains how to run Flow Analysis to expose bugs such as use of uninitialized memory, null pointer dereferencing, division by zero, memory and resource leaks.
Flow Analysis is a new type of static analysis technology that uses several analysis techniques, including simulation of application execution paths, to identify paths that could trigger runtime defects. Defects detected include use of uninitialized memory, null pointer dereferencing, division by zero, memory and resource leaks.
Since this analysis involves identifying and tracing complex paths, it exposes bugs that typically evade syntax-based static code analysis and unit testing, and would be difficult to find through manual testing or inspection. Flow Analysis' ability to expose bugs without executing code is especially valuable for users with legacy code bases and embedded code (where runtime detection of such errors is not effective or possible).
Analyzing Headers C/C++test does not directly analyze headers unless they are included by a source file under test. See How do I analyze header files/what files are analyzed? for details. |
Analyzing Template Functions C/C++test does perform static analysis of instantiated function templates and instantiated members of class templates. |
The general procedure for running Flow Analysis is:
By default, Flow Analysis performs a complete analysis of the scope it is run on. This can take considerable time when running on large code bases.
The most common way of performing Flow Analysis analysis is to run nightly tests on a single code base that changes slightly from day to day. Its incremental analysis mode is designed to reduce the time required to run analysis in this typical scenario. With incremental analysis mode, Flow Analysis memorizes important analysis data during the initial run, then reuses it during the subsequent runs—rerunning analysis only for parts of the code that have been modified or are tightly connected to the modified code.
When using incremental analysis, remember that:
Incremental Mode can be enabled using the controls in the Test Configuration manager’s Static tab. The available controls are detailed in Configuring Flow Analysis Analysis Options.
Swapping of analysis data mode is enabled by default. In this mode, analysis data is written to disk. Swapping of analysis data uses the same persistent storage and is done in a similar process as incremental analysis. If analysis is run on a large project, the analysis data that represents a semantical model of the analyzed source code may consume all the memory available for running Flow Analysis. If this occurs, Flow Analysis will remove from memory parts of the analysis data that are not currently necessary and reread it from disk later.If sufficient memory is available, swapping of analysis data may be disabled, which may speed up code analysis. For information on how to disable swapping of analysis data please refer to Enable swapping of analysis data to disk bullet in the Performance Tab Options topic.
The standard Flow Analysis Test Configuration includes all the Flow Analysis rules—except security rules and those that require customization. The fast configuration uses "Shallowest" depth of analysis and runs faster than the standard and aggressive configurations (see descriptions below). The fast configuration finds a moderate amount of problems and prevents violation number explosion. We recommend using this configuration to enforce Flow Analysis rules for any new project. If more rigorous analysis is required, consider switching to Flow Analysis Standard.
The "Flow Analysis Standard" Test Configuration includes all the Flow Analysis rules--except those that require customization. This configuration performs deeper analysis and may find more bugs than "Flow Analysis Fast". Standard also requires more time to run. We recommend switching to this configuration when finding more bugs is a higher priority. If you need to redefine some analysis parameters or reconfigure any of the rules, you can use this Test Configuration as a starting point.
We recommend the "Flow Analysis Aggressive" Test Configuration if you want C++test to report a violation for any suspect code. This configuration encourages Flow Analysis to report a violation any time that it suspects a problem—even in cases in which a false positive may be reported. Applying this configuration will result in more bugs being reported, but it can also increase the number of false alarms.
Flow Analysis performs interprocedural analysis that can cross boundaries of functions, classes, namespaces and compilation units within the scope of files selected for analysis. If there is a function call and the called function is defined in a different file, Flow Analysis will be able to trace the path inside the function—as long as the file containing it is included into analysis scope. Because of this, the precision of analysis highly depends on the scope.
Below are general guidelines for defining the scope of analysis (selecting which files are to be analyzed in a single session):
This topic covers how to analyze the bugs reported by Flow Analysis.
Flow Analysis findings are reported alongside static code analysis violations in Quality Tasks view. Flow Analysis content and format, however, is significantly different than that used for static code analysis violations. Results are organized into a prioritized task list that can be viewed by rule category or by severity. To view results by severity, open the Quality Tasks pull-down menu and choose Show> Details.
You can review results for analysis run from the GUI and results imported in the IDE (see Importing Results into the UI) in the Fix Static Analysis Violations category of the Quality Tasks view.
For tests run from the command line interface, rule violations are reported in the Static Analysis section of the report.
To view a detailed description of the reported bug type, right-click the bug message in the Quality Tasks view, then choose View Rule Documentation from the shortcut menu. A yellow "Yield" sign marks the node that you should right-click.
Test configurations that trigger violations can be opened from the Quality Tasks view: Right-click on a violation and choose View Test Configuration.
Quickly accessing test configuration from the violation is useful for group architects who are customizing tests and want to quickly disable rules that aren’t applicable. Developers importing results from a server-based run may also need to open and review test configurations that trigger violations.
In the Quality Tasks view, each Flow Analysis violation is represented by a hierarchical flow path that precisely describes the code that leads to the identified problem. Each element in the path is a line of code that is executed during runtime. If a flow path has a call to a function, the element representing that function call is a node whose subnodes represent execution flow within the called function. The final element in the execution path is always the point where the bug manifests itself. The complete path is presented in order to explain why there is a bug at the final point.
The elements of the flow path that are marked by the information icon have tool tips to help you analyze the flow that leads to the detected problem. Hover over an element to display the tool tip.
If you want to navigate through the code related to a reported execution path, use the Next Task Element and Previous Task Element buttons in the Quality Tasks view toolbar.
If the source code changes since Flow Analysis was run:
|
The path may contain ellipses that indicate the differences between paths when there is more than one path leading from the violation cause to the violation point.
By default, results are displayed using a compact path trace view, which shows only the essential executable statements in the defect path. This provides a quick overview of the various problems reported while still allowing you to drill down into the details in order to understand and repair each problem. Full path presentation is also available. See Compact vs Detailed Results Display for more details. |
Path elements that are important (with respect to the violation found) are marked with dark ball icons. Additionally, if you place your cursor over one of these specially-marked elements, a tooltip will explain why the element is considered important. For example, it might say "source of null value," "critical data flow," or "contains critical data flow" (output for function call nodes if they contain "important elements"). "Important elements" include violation cause, violation point, and all the elements which change the list of variables carrying data that leads to a violation. For example, assume the variable "a" carries a null pointer in the following excerpt:
1: b = a; 2: c = k; |
Line 1 is important in case a violation is later found on variable "b", and is specially marked.
Line 2 is not related to the variables carrying bad data, so it's not important and isn’t specially marked.
The violation itself is represented by an execution path with two marked points:
You can easily access the violation cause and violation point by right-clicking a reported violation (the node with the yellow caution icon), then choosing Show Violation Cause or Show Violation Point. from the shortcut menu.
The corresponding code will be highlighted in the editor:
This functionality is available in Visual Studio 2005 and later.
To highlight the source code referenced by a Flow Analysis violation message, simply double-click that message. An editor will open with the source code corresponding to the violation selected and the flow path highlighted in light blue. Any line at which an exception is thrown is marked with pink. All the lines which are important for the violation (violation cause, violation point, critical data flow) are highlighted in a dark color.If you want to navigate through the code related to a reported execution path, use the Next Violation Element and Previous Violation Element buttons in the Quality Tasks view toolbar.
Tips
|
By default, results are displayed using a compact path trace view, which shows only the essential executable statements in the defect path. This provides a quick overview of the various problems reported while still allowing you to drill down into the details in order to understand and repair each problem.
Full path presentation is also available. When a violation is shown in the detailed form, the expandable task node contains all the elements of the execution path on which Flow Analysis thinks the detected bug manifests itself. In other words, Flow Analysis will show the exact sequence of lines that are executed to produce this bug. This gives you complete information about the problem found and the assumptions that Flow Analysis made. Sometimes this information is absolutely essential for understanding why Flow Analysis reports a possible problem.
In many cases, such detailed information may not be necessary to understand the problem reported. In these cases, the compact form is convenient. When a violation is shown in the compact form, the expandable task node shows only the most important elements of the complete execution path on which Flow Analysis thinks the detected bug manifests itself. Flow Analysis treats the following execution path elements as important and shows in the compact view:
Here is an example of the detailed view:
Here is an example of the compact view for the same violation:
Even if the task view shows only the most important elements, all the path elements will be highlighted if a violation is selected and the corresponding code is shown in the IDE editor. Thus, you can use the compact view to get a quick assessment of the problem, then use the source editor to see the detailed execution path if you want more information about how the violation occurred.
To show the detailed view for a particular violation:
To always show the detailed view:
This topic explains how to customize Flow Analysis analysis—including what types of bugs detected, rule parameterization, analysis options, and the resources are checked by specific rules.
The types of bugs that Flow Analysis detects is determined by which rules you have enabled in the Test Configuration—in much the same way as you configure static code analysis with coding standards. The basic static analysis settings (maximum tasks reported per rule, etc.—see Static Tab Settings - Defining How Static Analysis is Performed for details) apply to both static code analysis and Flow Analysis analysis.
For example, if you want to disable or enable Flow Analysis rules, you can do so by checking/clearing boxes in the Test Configuration's rule tree (in the Static> Rules Tree tab).
Some rules are parameterized, meaning that you can customize their settings to make the analysis process more flexible and tailored to your unique project needs. As a result, Flow Analysis can even be used to detect violations bound to usage of very specific APIs.
For details on how to parameterize rules, see Customizing Parameterized Rules.
One common rule parameter is Report unvalidated violations.
To explain how this parameter works, let’s first look at the process of finding and reporting a violation. At first, Flow Analysis finds paths starting from the violation cause (the point where the bad or suspicious data originates) and ending at the violation point (the point where bad or suspicious data is used in a dangerous or suspicious operation). When Flow Analysis finds such a path violating a rule, it normally tries to validate the violation by verifying if the path is reachable from the beginning of the top-level function (the top-level function of the hierarchical representation of the violation path which may call other functions) of the violation path.
For example, here is a simple case where the violation path lies completely within a one function (no other functions are called from the violation path):
typedef struct SomeStruct {
int hashCode;
} SomeStruct;
extern SomeStruct* getObject();
void check(int initialized)
{
SomeStruct* obj;
if (initialized) {
obj = getObject();
} else {
obj = 0;
}
int hashCode = 0;
// some other actions
if (initialized) {
hashCode = obj->hashCode;
}
// some other actions
} |
When Flow Analysis analyzes this code, the following violation is found at first:
.C program.c (12): obj = 0; // Null value carrier: obj
. program.c (14): int hashCode = 0; // Null value carrier: obj
. program.c (16): if (initialized) { // Null value carrier: obj
.P program.c (17): hashCode = obj->hashCode; // Null value carrier: obj |
The next stage is to validate the violation by checking whether the path of the violation can be reached from the beginning of the function. During this stage, Flow Analysis determines that "obj" can be assigned a null value only if "initialized" is false. However, in this case, the line where dereferencing occurs is not reachable. This is an example of how validating violation paths by verifying their reachability from the beginning of violation's top-level function can help to eliminate false positives. If the example was different and the path was reachable from the beginning of the function, the violation would pass validation—and in the detailed path mode, Flow Analysis would show the violation with the completed path, starting from the beginning of the top-level function, to explain how exactly it thinks the path may be reachable.
In some complicated cases, restricted analysis depth (used to keep analysis speed at a reasonable level) may prevent Flow Analysis from completing the violation validation procedure. If that happens, the violation remains unvalidated and Flow Analysis does not know whether it is reachable from the beginning of the corresponding function. In this case, the Report unvalidated violations parameter determines whether the violation is reported. Enabling this option increases the number of defects discovered by Flow Analysis, but it can also increase the number of false positives.
Additionally, you can control specific Flow Analysis options, such as analysis depth, support for multithreading APIs, and violation reporting verbosity, by modifying the parameters in the Test Configuration’s Static> Flow Analysis Advanced Settings tab.
The available options in each subtab are described in the following sections:
In the Verbosity subtab, you can configure the following options:
Violations containing only the violation point may be difficult to understand (compared to regular cases where Flow Analysis shows complete paths starting from violation causes and leading to violation points). That’s why we provide an option to hide violations where the cause cannot be shown.
See the example below for additional details.
Example - Impact of "Do not report violations when cause cannot be shown"
The following sample code causes a multi-cause violation of the BD.PB-SWITCH rule to be reported only when Do not report violations when cause cannot be shown is enabled:
#include "stdio.h"
enum Figures {
SPHERE,
CIRCLE,
CUBE,
SQUARE,
HIMESPHERE
};
static void guessFigure(int round, int volumetric)
{
int figure;
if (round && volumetric) {
figure = SPHERE; /* CAUSE 1 */
} else if (round && !volumetric) {
figure = CIRCLE; /* CAUSE 2 */
} else if (!round && volumetric) {
figure = CUBE; /* CAUSE 3 */
} else {
figure = SQUARE; /* CAUSE 4 */
}
switch (figure) {
case SQUARE:
printf("This is a sphere");
break;
case HIMESPHERE:
printf("This is a hemispere");
break;
case CIRCLE:
printf("This is a circle");
break;
case CUBE:
printf("This is a cube");
break;
default:
printf("This is a square");
break;
}
} |
This tab allows you to define functions that terminate application execution. C/C++ developers sometimes use functions that terminate application execution in the event of a fatal error from which recovery is impossible. Examples of such functions are abort() and exit() from the standard library. Since Flow Analysis analyzes the application’s execution flow, it's important for it to be aware of the terminating functions that break execution flow by immediately stopping the application. Without such knowledge, Flow Analysis might make incorrect assumptions about the application flow.
Flow Analysis is aware of the terminating functions that are defined in the standard library. However, this is often not sufficient because non-standard libraries define their own terminating functions. If your application uses one of these functions, you should communicate that to Flow Analysis by specifying the custom terminating function in this tab. Otherwise, Flow Analysis may produce false positives with execution paths passing by terminating functions.
Use the table listing supported APIs to enable/disable terminators from various APIs as well as to define your own APIs containing terminating functions. To add information about terminating functions from a certain library click Add, type the name of the library and press <Enter>. A new entry will be added to the terminators APIs table. Next, click the "Edit" button and complete the table that opens; the table has the following columns:
This tab allows you to define functions for synchronization between threads as well as to activate/deactivate known multithreading functions. The information defined here affects the behavior of rules from the BD.TRS (Threads and Synchronization) category. These rules will check all the functions that are defined and activated on this tab.
Use the table that lists supported APIs to enable/disable synchronization functions from various APIs as well as to define your own APIs containing synchronization functions. To add information about synchronization functions from a certain library, click Add, type the name of the library and press <Enter>. A new entry will be added to the multithreading APIs table. Next, click Edit and complete the dialog to define particular synchronization functions. This dialog allows you to define the following types of functions:
These functions are defined in much the same was as resources (described in Specifying Resources to Check for BD.RES Rules).
Allows you to define which resources the BD.RES category (Resources) rules should check. These rules check for the correct usage of all resources that are defined and enabled on this tab.
For details on configuring these resource checking settings, see the following section.
Specifying Resources to Check for BD.RES Rules
The Test Configuration manager’s Static> Flow Analysis Advanced Options> Resources tab allows you to define which resources the BD.RES category (Resources) rules should check. These rules check for the correct usage of all resources that are defined and enabled on this tab.
You can use the table to enable/disable checking for various types of resources. The Add, Remove, and Edit buttons can be used to manage custom resources.
To add information about resources from a certain library:
Configuring Resource Allocators
The Resource allocators table can be completed with the descriptors of functions that can produce a resource. The table has the following columns:
It is common that allocation functions return an error code to indicate allocation failure. When an allocation function returns a pointer to a resource, a NULL pointer normally indicates an allocation failure. When Flow Analysis is looking for resource leaks, it needs to understand if allocation succeeded or failed; this helps it report only missing calls to deallocation functions on paths where allocation actually occurred. In cases where a resource allocator function returns a pointer to a resource, Flow Analysis assumes that the resource is successfully allocated if the pointer is not NULL.
Configuring Resource Closers
The Resource closers table can be completed with the descriptors of functions that can close a resource. The table has the following columns:
Configuring Resource Checkers
The Resource checkers table can be completed with the descriptors of functions that can check if the resource is open. The table has the following columns:
true or false.Configuring Safe Functions
The Safe functions table can be completed with the descriptors of functions that can be safely called on a closed resource – without triggering the BD-RES-FREE rule. The table has the following columns:
Resources with Built-In Support
'glob' results (glob.h)
Corresponds to 'glob_t' structures allocated by calls to:
int glob(const char *pattern, int flags,
int (*errfunc) (const char *epath, int eerrno),
glob_t *pglob); |
'hostent' structures (hostent.h)
Corresponds to 'glob_t' structures allocated by calls to:
struct hostent *getipnodebyname(const char *name, int af, int flags, int error_num); struct hostent *getipnodebyaddr(const void *addr, size_t len, int af, int error_num); |
Socket address structures (netdb.h)
Corresponds to 'addrinfo' structures allocated by calls to:
int getaddrinfo(const char *node, const char *service, const struct addrinfo hints, struct addrinfo **res); |
Defining Custom Resources
For an example of how custom resources are defined, consider the following plain C code using a non-standard resource:
/* returns NULL on allocation failure */
void* myAlloc(void);
void myDealloc(void*);
static void createMyResource_Leak()
{
void* resource = myAlloc();
} /* 'res' is not closed on the path where it is not NULL */
static void createMyResource_NoLeak()
{
void* resource = myAlloc();
if (!resource) {
return; /* no leak here, if res is NULL, it means allocation failed */
}
/* use the resource */
myDealloc(resource);
} |
We want to define methods allocating/deallocating the resource so that Flow Analysis can be used to find leaks of this non-standard resource. To achieve this, we need to perform the following steps:
myAlloc as an allocator as follows:Now let's consider a different example. Here, a resource-opening function receives a pointer to a resource handle as a parameter and initializes it with the handle of the newly allocated resource. An error code of -1 is returned if the allocation fails.
int openMyResource(int* pHandle);
void closeMyResource(int handle);
static void openMyResource_Leak()
{
int handle;
openMyResource(&handle);
} // 'res' is not closed
static void openMyResource_NoLeak()
{
int handle;
int status = openMyResource(&handle);
if (status == -1) {
return; // no leak here, status == -1 indicates allocation failure
}
// use the resource
closeMyResource(handle);
} |
Now let's add support for this type of resource in Flow Analysis by performing the following actions:
openMyResource as an allocator as follows:When performing code analysis, Flow Analysis processes definitions of functions that are defined in source and header files under test. Functions that are defined in header files outside the testing scope are not analyzed, and Flow Analysis is not aware of their semantics. If Flow Analysis requires information about function definitions that are defined in header files outside the testing scope, you can configure the following options:
External files to analyze: Specifies absolute paths to additional header files to be analyzed by Flow Analysis. Use wildcards to specify the pattern.
External functions to analyze: Specifies additional functions to be analyzed by Flow Analysis. Complete the table with the following information:
The Always analyzed functions option allows you to define functions that will always be analyzed when encountered on the execution path. This helps you ensure that the rule will analyze functions it would normally not enter when checking a given path.
Select the Enable checkbox and provide following information:
Internal representation of the "errno" value: The Standarddefineserno to be a modifiable lvalue of type int. It is unspecified whetherer rno is a macro or an identifier declared with an external linkage. Implementations may use the global variable "errno" or "__errno", or apply the "(*errno_function())" pattern with different names of the called functions. This option allows you to specify the names of these variables and functions with regular expressions:
Internal representation of the call to a function from the header <ctype.h>: The Standard specifies several functions to be defined in the header <ctype.h>. Some implementations (e.g GNU GCC in the C mode) define these functions as macros that expand to the code which tests an element of the internal array against some flags. This can be either a global array or a pointer returned by a function. This option allows you to specify names of these variables and functions with regular expressions: