List of all issue types
Here is an overview of the issue types currently reported by Infer.
ARBITRARY_CODE_EXECUTION_UNDER_LOCKβ
Reported as "Arbitrary Code Execution Under lock" by starvation.
A call that may execute arbitrary code (such as registered, or chained, callbacks) is made while holding a lock. This code may deadlock whenever the callbacks obtain locks themselves, so it is an unsafe pattern.
Example:
SettableFuture future = null;
public void callFutureSet() {
future.set(null);
}
// synchronized means it's taking a lock implicitly
public synchronized void example_of_bad_pattern() {
callFutureSet(); // <- issue reported here
}
// If the call is made while holding multiple locks, the warning
// will be issued only at the innermost lock acquisition. Here we
// report in example_of_bad_pattern but we won't report below.
public void nested_bad_pattern_no_report(Object o) {
synchronized (o) {
example_of_bad_pattern(); // <- no issue reported
}
}
BAD_ARGβ
Category: Runtime exception. Reported as "Bad Arg" by pulse.
Bad arg in Erlang: Reports an error when the type of an argument is wrong or the argument is badly formed. Corresponds to the badarg
error in the Erlang runtime.
For example, trying to concatenate the number 3
with the list [1,2]
gives badarg
error because 3
is not a list.
f() ->
3 ++ [1,2]. // badarg error
Note that although the first argument needs to be a list, the second argument may not be a list.
For instance, concatenating [1,2] with the number 3
raises no error in Erlang.
g() ->
[1,2] ++ 3. // no error. Result: [1,2|3]
BAD_ARG_LATENTβ
Category: Runtime exception. Reported as "Bad Arg Latent" by pulse.
A latent BAD_ARG. See the documentation on Pulse latent issues.
BAD_GENERATORβ
Category: Runtime exception. Reported as "Bad Generator" by pulse.
Bad generator in Erlang: Reports an error when a wrong type is used in a generator. Corresponds to the bad_generator
error in the Erlang runtime.
For example:
list_instead_of_map() ->
M = [],
[{K, V} || K := V <- M]
BAD_GENERATOR_LATENTβ
Category: Runtime exception. Reported as "Bad Generator Latent" by pulse.
A latent BAD_GENERATOR. See the documentation on Pulse latent issues.
BAD_KEYβ
Category: Runtime exception. Reported as "Bad Key" by pulse.
Bad key in Erlang: Reports an error when trying to access or update a non-existing key in a map. Corresponds to the {badkey,K}
error in the Erlang runtime.
For example, trying to update the key 2
in M
gives {badkey,2}
error because 2
is not present as a key in M
.
f() ->
M = #{},
M#{2 := 3}.
Note that maps currently use a recency abstraction, meaning that only the most recent key/value is tracked. Therefore, if a map is non-empty and we try to access a key other than the one we track, we just assume that it is there to avoid false positives.
BAD_KEY_LATENTβ
Category: Runtime exception. Reported as "Bad Key Latent" by pulse.
A latent BAD_KEY. See the documentation on Pulse latent issues.
BAD_MAPβ
Category: Runtime exception. Reported as "Bad Map" by pulse.
Bad map in Erlang: Reports an error when trying to access or update a key for a term that is not a map. Corresponds to the {badmap,...}
error in the Erlang runtime.
For example, trying to update L
as if it was a map gives {badmap,[1,2,3]}
error because L
is actually a list ([1,2,3]
).
f() ->
L = [1,2,3],
L#{1 => 2}.
BAD_MAP_LATENTβ
Category: Runtime exception. Reported as "Bad Map Latent" by pulse.
A latent BAD_MAP. See the documentation on Pulse latent issues.
BAD_RECORDβ
Category: Runtime exception. Reported as "Bad Record" by pulse.
Bad record in Erlang: Reports an error when trying to access or update a record with the wrong name. Corresponds to the {badrecord,Name}
error in the Erlang runtime.
For example, accessing R
as a person
record gives {badrecord,person}
error because R
is rabbit
(even though both share the name
field).
-record(person, {name, phone}).
-record(rabbit, {name, color}).
f() ->
R = #rabbit{name = "Bunny", color = "Brown"},
R#person.name.
BAD_RECORD_LATENTβ
Category: Runtime exception. Reported as "Bad Record Latent" by pulse.
A latent BAD_RECORD. See the documentation on Pulse latent issues.
BAD_RETURNβ
Reported as "Bad Return" by pulse.
Bad return in Erlang: The dynamic type of a returned value disagrees with the static type given in the spec.
For example, this function returns an integer, while the spec says it returns an atom.
-spec f() -> atom().
f() -> 1.
Note that this will not lead to a runtime error when running the Erlang program.
BAD_RETURN_LATENTβ
Reported as "Bad Return Latent" by pulse.
A latent BAD_RETURN. See the documentation on Pulse latent issues.
BIABDUCTION_MEMORY_LEAKβ
Category: Resource leak. Reported as "Memory Leak" by biabduction.
See MEMORY_LEAK_C.
BIABDUCTION_RETAIN_CYCLEβ
Category: Resource leak. Reported as "Retain Cycle" by biabduction.
See RETAIN_CYCLE.
BLOCK_PARAMETER_NOT_NULL_CHECKEDβ
Reported as "Block Parameter Not Null Checked" by parameter-not-null-checked.
This error type is reported only in Objective-C/Objective-C++. It happens when a method has a block as a parameter,
and the block is executed in the method's body without checking it for nil
first. If a nil
block is passed to
the method, then this will cause a crash. For example:
- (void)uploadTaskWithRequest:(NSURLRequest*)urlRequest
fromFile:(NSURL*)fileURL
delegate:(id)delegate
delegateQueue:(NSOperationQueue*)delegateQueue
completion:(void (^)())completion {
...
completion();
}
Action:
Possible solutions are adding a check for nil
, or making sure that the method
is not ever called with nil
. When an argument will never be nil
, you can add
the annotation nonnull
to the argument's type, to tell Infer (and the type
system), that the argument won't be nil
. This will silence the warning.
BUFFER_OVERRUN_L1β
Reported as "Buffer Overrun L1" by bufferoverrun.
This is reported when outside of buffer bound is accessed. It can corrupt memory and may introduce security issues in C/C++.
For example, int a[3]; a[5] = 42;
generates a BUFFER_OVERRUN_L1
on a[5] = 42;
.
Buffer overrun reports fall into several "buckets" corresponding to the expected precision of the report. The higher the number, the more likely it is to be a false positive.
-
L1
: The most faithful report, when it must be unsafe. For example, array size:[3,3]
, offset:[5,5]
. -
L2
: Less faithful report thanL1
, when it may be unsafe. For example, array size:[3,3]
, offset:[0,5]
. Note that the offset may be a safe value in the real execution, i.e. safe when 0, 1, or 2; unsafe when 3, 4, or 5. -
L5
: The least faithful report, when there is an interval top. For example, array size:[3,3]
, offset:[-oo,+oo]
. -
L4
: More faithful report thanL5
, when there is an infinity value. For example, array size:[3,3]
, offset:[0, +oo]
. -
L3
: The reports that are not included in the above cases. -
S2
: An array access is unsafe by symbolic values. For example, array size:[n,n]
, offset[n,+oo]
. -
U5
: An array access is unsafe by unknown values, which are usually from unknown function calls.