...
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.
| Info | ||
|---|---|---|
| ||
Important An optional Flow Analysis license (with C++test Automation Edition) is required to use Flow Analysis. |
Running Flow Analysis
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.
...
- Identify or create a Test Configuration with your preferred Flow Analysis standard analysis settings.
- For a description of preconfigured Test Configurations, see Built-in Test Configurations.
- For general procedures related to configuring and sharing Test Configurations, see the Configuring Test Configurations and Rules for Policies. For details on C/C++test-specific Flow Analysis options, see Static Tab Settings - Defining How Static Analysis is Performed.
- Start the test using the preferred Test Configuration.
- For details on testing from the GUI, see Testing from the GUI.
- For details on testing from the command line, see Testing from the Command Line Interface.
- Review and respond to the results.
- For details, see Reviewing Flow Analysis Static Analysis Results.
- (Optional) Fine-tune Flow Analysis settings as needed.
- For details, see Customizing Flow Analysis Static Analysis.
Configuring Batch-Mode Flow Analysis Analysis with cpptestcli
Regularly-schedule batch-mode Flow Analysis analysis should simply execute a built-in or custom Test Configuration that analyzes your project according to the Flow Analysis rules important to your team.
For example:
cpptestcli -data /path/to/workspace -resource "ProjectToTest" -config team://DataFlowAnalysis -publish
...
...
| Anchor | ||||
|---|---|---|---|---|
|
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
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.
...
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.In general, we recommend running C++test in a large JVM heap configured with the Xmx JVM option. This is to minimize swapping, which results in greater performance.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.
...
- Do not report violations when cause cannot be shown: Determines whether Flow Analysis reports violations where causes cannot be shown.
Some Flow Analysis rules require that Flow Analysis checks all the possible paths leading to a certain point and verifies that a certain condition is met for all those paths. In such cases, a violation is associated with a set of paths (whereas in simple cases, a violation is represented by only one path). All of the paths in such a violation end with the violation point common to all the paths in the violation. However, different paths may start at different points in code. The beginning of each path is a violation cause (a point in code which stipulates a violation of a certain condition later in the code at the violation point). If a multipath violation's different paths have different causes, Flow Analysis will show only the violation point (and not the violation causes).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.
- Do not report violations whose paths pass via inline assembly code: Prevents the reporting of violations whose paths pass via inline assembly code instructions.Level of reporting similar violations (i.e those that share a violation point, or both the point and the cause): Allows you to determine whether Flow Analysis reports all the violations that it can find in the analyzed code or if it hides some of them. Available options are:
- Report all similar violations: Reports all identified Flow Analysis violations.
- Do not show more than one violation with the same cause and violation point: Prevents the reporting of duplicate Flow Analysis violations. Duplicate violations are those that share the same violation cause and the same violation point (even though their flow paths may be different). Do not show more than one violation per suspicious point: Restricts reporting report more than one violation per point: Restricts reporting to one violation (for a single rule) per suspicious pointviolation point. For example, one violation will be reported when Flow Analysis detects a potential null dereference with multiple sources of the null value. When verbosity is set to this level, Flow Analysis performance is somewhat faster.
- Do not report violations whose paths pass via inline assembly code: Prevents the reporting of violations whose paths pass via inline assembly code instructions.
Example - Impact of "Do not report violations when cause cannot be shown"
...