Static Code Analysis Using Infer

1. Introduction

In the realm of software development, ensuring code quality is very important, especially for complex and large codebases. Static code analysis tools like Infer provide us with techniques to detect potential bugs and vulnerabilities in our codebase before they manifest into critical issues.

In this tutorial, we’ll explore the fundamentals of code analysis, explore Infer’s capabilities, and provide practical insights into incorporating it into our development workflow.

2. Static Code Analysis

Static analysis is a debugging method that automatically examines source code without executing the program. This process facilitates the identification of potential defects, security vulnerabilities, and maintainability issues. Typically conducted by third-party tools like the well-known SonarQube, static code analysis is straightforward when automated.

Generally, it occurs in early development phases. Once the code is written, a static code analyzer should be run to look over the code. It will check against defined coding rules from standards or custom predefined rules. Once the code is run through the static code analyzer, the analyzer will have identified whether or not the code complies with the set rules.

In a basic enterprise environment, it’s often part of the Continuous Integration (CI) process. With each commit, a job is triggered to build the application, run tests, and analyze the code, ensuring compliance, safety, and security before deployment.

3. Infer

Infer is a static code analysis tool for Java, C, C++, and Objective-C, written in OCaml. It was first developed at Facebook and open-sourced in 2015. Since then, it has gained popularity beyond Facebook, being adopted by other large companies.

For Java and Android code, it checks for issues like null pointer exceptions, resource leaks, and concurrency race conditions. In C, C++, and Objective-C, it detects problems such as null pointer issues, memory leaks, coding convention violations, and calls to unavailable APIs.

To efficiently handle large codebases, Infer utilizes techniques like separation logic and bi-abduction. Separation logic allows it to analyze small parts of the code storage independently, avoiding the need to process the entire memory space at once. Bi-abduction is a logical inference method that helps Infer discover properties about different parts of the code, allowing it to focus only on the modified sections during subsequent analyses.

By combining these approaches, this tool can find complex problems in modifications to an application built from millions of lines of code in a short time.

3.1. Infer Phases

Infer operates in two main phases regardless of the input language: the capture phase and the analysis phase.

During the capture phase, Infer captures compilation commands to translate the files for analysis into its internal intermediate language. This translation is similar to compilation, so Infer takes information from the compilation process to perform its own translation. Also, this is the reason why we call Infer with a compilation command such as:

infer run -- javac File.java

Therefore, the files get compiled as usual, and Infer also translates them to be analyzed in the second phase. Infer stores the intermediate files in the results directory, which is called infer-out/by default and is created in the folder where the infer command is invoked.

Also, we can invoke only the capture phase using the capture subcommand:

infer capture -- javac File.java

In the analysis phase, files in infer-out/ are analyzed individually by Infer. Each function and method is analyzed separately. If Infer encounters an error during the analysis of a method or function, it stops analysis for that specific entity but continues with others. Hence, a typical workflow involves running Infer on the code, addressing identified errors, and rerunning Infer to discover additional issues or confirm fixes.

Detected errors are reported in the standard output and in a file named infer-out/report.txt. Infer filters and highlight bugs that are most likely to be authentic.

We can invoke only the analysis phase using the analyze subcommand:

infer analyze

3.2. Infer Global and Differential Workflows

By default, Infer will delete the previous infer-out/ directory if existing. This leads to a global workflow, where the entire project is analyzed each time.

Passing –reactive or -r to Infer prevents in from deleting infer-out/ directory, leading to a differential workflow. For example, mobile apps use incremental build systems, where code evolves as a sequence of code changes. For these changes, it would make sense to analyze only the current changes in the project, instead of analyzing the whole project each time. Therefore, we can take advantage of Infer’s reactive mode and switch to a differential workflow.

3.3. Analyzing Projects

To analyze files with Infer we can use compilers such as javac and clang. Also, we can use gcc, although Infer will use clang internally. Moreover, we can use Infer with various build systems.

One popular build system for Java is Maven, and we can use together with Infer in the following way:

infer run -- mvn <maven target>

Also, we can use Infer together with Gradle:

infer run -- gradle <gradle task>

3.4. Recommended Flow for CI

Infer recommends using the differential workflow for Continuous Integration (CI). Therefore, the flow would be to determine the modified files and run the analysis in reactive mode. Also, if we would like to run more than one analyzer, it is more efficient to separate the capture phase, so that the result can be used by all the analyzers.

4. Running Infer

We have multiple options to use Infer: binary releases, build Infer from source, or Docker images. Getting started with the Infer page explains how we can get and run Infer.

Now, we can create some dummy Java code snippets and analyze them. Not that we will cover only a few issues Infer can identify, and a complete list of all types of issues that can be detected by Infer can be found here.

4.1. Null Dereference

public class NullPointerDereference {
    public static void main(String[] args) {
        NullPointerDereference.nullPointerDereference();
    }
    private static void nullPointerDereference() {
        String str = null;
        int length = str.length();
    }
}

If we Infer against this code, we’ll have the following output:

Analyzed 1 file
Found 1 issue
./NullPointerDereference.java:11: error: NULL_DEREFERENCE
  object str last assigned on line 10 could be null and is dereferenced at line 11
   9.       private static void nullPointerDereference() {
  10.           String str = null;
  11. >         int length = str.length();
  12.       }
  13.   }
  24.   
Summary of the reports
  NULL_DEREFERENCE: 1

4.2. Resource Leak

public class ResourceLeak {
    public static void main(String[] args) throws IOException {
        ResourceLeak.resourceLeak();
    }
    private static void resourceLeak() throws IOException {
        FileOutputStream stream;
        try {
            File file = new File("randomName.txt");
            stream = new FileOutputStream(file);
        } catch (IOException e) {
            return;
        }
        stream.write(0);
    }
}

Now, by running Infer, we can see that a resource leak was detected:

Analyzed 1 file
Found 1 issue
./ResourceLeak.java:21: error: RESOURCE_LEAK
   resource of type java.io.FileOutputStream acquired to stream by call to FileOutputStream(...) at line 17 is not released after line 21
  19.               return;
  20.           }
  21. >         stream.write(0);
  22.       }
  23.   }
  24.   
Summary of the reports
  RESOURCE_LEAK: 1

4.3. Division by Zero

public class DivideByZero {
    public static void main(String[] args) {
        DivideByZero.divideByZero();
    }
    private static void divideByZero() {
        int dividend = 5;
        int divisor = 0;
        int result = dividend / divisor;
    }
}

The following output is displayed for our code:

Analyzed 1 file
Found 1 issue
./DivideByZero.java:9: error: DIVIDE_BY_ZERO
  The denominator for division is zero, which triggers an Arithmetic exception.
  6. private static void divideByZero() {
  7.     int dividend = 5;
  8.     int divisor = 0;
  9. >    int result = dividend / divisor;
  10. }
Summary of the reports
DIVIDE_BY_ZERO: 1

5. Conclusion