2019-10-19 08:08:17 +08:00
|
|
|
// RUN: %clang_analyze_cc1 %s -std=c++14 \
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
// RUN: -verify=expected,tracking \
|
|
|
|
|
// RUN: -analyzer-config track-conditions=true \
|
|
|
|
|
// RUN: -analyzer-output=text \
|
|
|
|
|
// RUN: -analyzer-checker=core
|
2019-07-05 22:00:08 +08:00
|
|
|
|
2019-10-19 08:08:17 +08:00
|
|
|
// RUN: not %clang_analyze_cc1 -std=c++14 -verify %s \
|
2019-07-05 22:00:08 +08:00
|
|
|
// RUN: -analyzer-checker=core \
|
2019-08-22 11:08:48 +08:00
|
|
|
// RUN: -analyzer-config track-conditions=false \
|
2019-07-05 22:00:08 +08:00
|
|
|
// RUN: -analyzer-config track-conditions-debug=true \
|
|
|
|
|
// RUN: 2>&1 | FileCheck %s -check-prefix=CHECK-INVALID-DEBUG
|
|
|
|
|
|
|
|
|
|
// CHECK-INVALID-DEBUG: (frontend): invalid input for analyzer-config option
|
|
|
|
|
// CHECK-INVALID-DEBUG-SAME: 'track-conditions-debug', that expects
|
|
|
|
|
// CHECK-INVALID-DEBUG-SAME: 'track-conditions' to also be enabled
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
//
|
2019-10-19 08:08:17 +08:00
|
|
|
// RUN: %clang_analyze_cc1 %s -std=c++14 \
|
2019-07-05 22:00:08 +08:00
|
|
|
// RUN: -verify=expected,tracking,debug \
|
|
|
|
|
// RUN: -analyzer-config track-conditions=true \
|
|
|
|
|
// RUN: -analyzer-config track-conditions-debug=true \
|
|
|
|
|
// RUN: -analyzer-output=text \
|
|
|
|
|
// RUN: -analyzer-checker=core
|
|
|
|
|
|
2019-10-19 08:08:17 +08:00
|
|
|
// RUN: %clang_analyze_cc1 %s -std=c++14 -verify \
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
// RUN: -analyzer-output=text \
|
2019-08-22 11:08:48 +08:00
|
|
|
// RUN: -analyzer-config track-conditions=false \
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
// RUN: -analyzer-checker=core
|
|
|
|
|
|
|
|
|
|
namespace example_1 {
|
|
|
|
|
int flag;
|
|
|
|
|
bool coin();
|
|
|
|
|
|
|
|
|
|
void foo() {
|
2019-08-22 04:43:27 +08:00
|
|
|
flag = coin(); // tracking-note-re{{{{^}}Value assigned to 'flag', which participates in a condition later{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void test() {
|
2019-08-22 04:43:27 +08:00
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
flag = 1;
|
|
|
|
|
|
|
|
|
|
foo(); // TODO: Add nodes here about flag's value being invalidated.
|
2019-08-22 04:43:27 +08:00
|
|
|
if (flag) // expected-note-re {{{{^}}Assuming 'flag' is 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking false branch{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
x = new int;
|
|
|
|
|
|
2019-08-22 04:43:27 +08:00
|
|
|
foo(); // tracking-note-re{{{{^}}Calling 'foo'{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Returning from 'foo'{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
|
2019-08-22 04:43:27 +08:00
|
|
|
if (flag) // expected-note-re {{{{^}}Assuming 'flag' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
2019-07-05 22:00:08 +08:00
|
|
|
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
} // end of namespace example_1
|
|
|
|
|
|
|
|
|
|
namespace example_2 {
|
|
|
|
|
int flag;
|
|
|
|
|
bool coin();
|
|
|
|
|
|
|
|
|
|
void foo() {
|
2019-08-22 04:43:27 +08:00
|
|
|
flag = coin(); // tracking-note-re{{{{^}}Value assigned to 'flag', which participates in a condition later{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void test() {
|
|
|
|
|
int *x = 0;
|
|
|
|
|
flag = 1;
|
|
|
|
|
|
|
|
|
|
foo();
|
2019-08-22 04:43:27 +08:00
|
|
|
if (flag) // expected-note-re {{{{^}}Assuming 'flag' is 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking false branch{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
x = new int;
|
|
|
|
|
|
2019-08-22 04:43:27 +08:00
|
|
|
x = 0; // expected-note-re{{{{^}}Null pointer value stored to 'x'{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
|
2019-08-22 04:43:27 +08:00
|
|
|
foo(); // tracking-note-re{{{{^}}Calling 'foo'{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Returning from 'foo'{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
|
2019-08-22 04:43:27 +08:00
|
|
|
if (flag) // expected-note-re {{{{^}}Assuming 'flag' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
2019-07-05 22:00:08 +08:00
|
|
|
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
} // end of namespace example_2
|
|
|
|
|
|
|
|
|
|
namespace global_variable_invalidation {
|
|
|
|
|
int flag;
|
|
|
|
|
bool coin();
|
|
|
|
|
|
|
|
|
|
void foo() {
|
|
|
|
|
// coin() could write bar, do it's invalidated.
|
2019-08-22 04:43:27 +08:00
|
|
|
flag = coin(); // tracking-note-re{{{{^}}Value assigned to 'flag', which participates in a condition later{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Value assigned to 'bar', which participates in a condition later{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int bar;
|
|
|
|
|
|
|
|
|
|
void test() {
|
2019-08-22 04:43:27 +08:00
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
flag = 1;
|
|
|
|
|
|
2019-08-22 04:43:27 +08:00
|
|
|
foo(); // tracking-note-re{{{{^}}Calling 'foo'{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Returning from 'foo'{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
|
2019-08-22 04:43:27 +08:00
|
|
|
if (bar) // expected-note-re {{{{^}}Assuming 'bar' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'bar'{{$}}}}
|
|
|
|
|
if (flag) // expected-note-re {{{{^}}Assuming 'flag' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
2019-07-05 22:00:08 +08:00
|
|
|
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
} // end of namespace global_variable_invalidation
|
|
|
|
|
|
|
|
|
|
namespace variable_declaration_in_condition {
|
|
|
|
|
bool coin();
|
|
|
|
|
|
|
|
|
|
bool foo() {
|
2019-08-14 07:22:33 +08:00
|
|
|
return coin();
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int bar;
|
|
|
|
|
|
|
|
|
|
void test() {
|
2019-08-22 04:43:27 +08:00
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
|
2019-08-22 04:43:27 +08:00
|
|
|
if (int flag = foo()) // debug-note-re{{{{^}}Tracking condition 'flag'{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Assuming 'flag' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-2{{{{^}}Taking true branch{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
|
|
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
} // end of namespace variable_declaration_in_condition
|
|
|
|
|
|
|
|
|
|
namespace conversion_to_bool {
|
|
|
|
|
bool coin();
|
|
|
|
|
|
|
|
|
|
struct ConvertsToBool {
|
2019-08-14 07:22:33 +08:00
|
|
|
operator bool() const { return coin(); }
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
void test() {
|
2019-08-22 04:43:27 +08:00
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
|
|
|
|
|
if (ConvertsToBool())
|
2019-08-22 04:43:27 +08:00
|
|
|
// debug-note-re@-1{{{{^}}Tracking condition 'ConvertsToBool()'{{$}}}}
|
|
|
|
|
// expected-note-re@-2{{{{^}}Assuming the condition is true{{$}}}}
|
|
|
|
|
// expected-note-re@-3{{{{^}}Taking true branch{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
} // end of namespace variable_declaration_in_condition
|
|
|
|
|
|
2019-08-14 17:39:38 +08:00
|
|
|
namespace note_from_different_but_not_nested_stackframe {
|
|
|
|
|
|
|
|
|
|
void nullptrDeref(int *ptr, bool True) {
|
2019-08-22 04:43:27 +08:00
|
|
|
if (True) // expected-note-re{{{{^}}'True' is true{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'True'{{$}}}}
|
2019-08-14 17:39:38 +08:00
|
|
|
*ptr = 5;
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer (loaded from variable 'ptr')}}
|
|
|
|
|
// expected-warning@-2{{Dereference of null pointer (loaded from variable 'ptr')}}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void f() {
|
|
|
|
|
int *ptr = nullptr;
|
2019-08-22 04:43:27 +08:00
|
|
|
// expected-note-re@-1{{{{^}}'ptr' initialized to a null pointer value{{$}}}}
|
2019-08-14 17:39:38 +08:00
|
|
|
bool True = true;
|
|
|
|
|
nullptrDeref(ptr, True);
|
2019-08-22 04:43:27 +08:00
|
|
|
// expected-note-re@-1{{{{^}}Passing null pointer value via 1st parameter 'ptr'{{$}}}}
|
|
|
|
|
// expected-note-re@-2{{{{^}}Calling 'nullptrDeref'{{$}}}}
|
2019-08-14 17:39:38 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
} // end of namespace note_from_different_but_not_nested_stackframe
|
|
|
|
|
|
2019-08-14 07:22:33 +08:00
|
|
|
namespace important_returning_pointer_loaded_from {
|
|
|
|
|
bool coin();
|
|
|
|
|
|
|
|
|
|
int *getIntPtr();
|
|
|
|
|
|
|
|
|
|
void storeValue(int **i) {
|
2019-08-22 04:43:27 +08:00
|
|
|
*i = getIntPtr(); // tracking-note-re{{{{^}}Value assigned to 'i', which participates in a condition later{{$}}}}
|
2019-08-14 07:22:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int *conjurePointer() {
|
|
|
|
|
int *i;
|
2019-08-22 04:43:27 +08:00
|
|
|
storeValue(&i); // tracking-note-re{{{{^}}Calling 'storeValue'{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Returning from 'storeValue'{{$}}}}
|
|
|
|
|
return i; // tracking-note-re{{{{^}}Returning pointer (loaded from 'i'), which participates in a condition later{{$}}}}
|
2019-08-14 07:22:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void f(int *ptr) {
|
2019-08-22 04:43:27 +08:00
|
|
|
if (ptr) // expected-note-re{{{{^}}Assuming 'ptr' is null{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking false branch{{$}}}}
|
2019-08-14 07:22:33 +08:00
|
|
|
;
|
|
|
|
|
if (!conjurePointer())
|
2019-08-22 04:43:27 +08:00
|
|
|
// tracking-note-re@-1{{{{^}}Calling 'conjurePointer'{{$}}}}
|
|
|
|
|
// tracking-note-re@-2{{{{^}}Returning from 'conjurePointer'{{$}}}}
|
|
|
|
|
// debug-note-re@-3{{{{^}}Tracking condition '!conjurePointer()'{{$}}}}
|
|
|
|
|
// expected-note-re@-4{{{{^}}Assuming the condition is true{{$}}}}
|
|
|
|
|
// expected-note-re@-5{{{{^}}Taking true branch{{$}}}}
|
2019-08-14 07:22:33 +08:00
|
|
|
*ptr = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
} // end of namespace important_returning_pointer_loaded_from
|
|
|
|
|
|
|
|
|
|
namespace unimportant_returning_pointer_loaded_from {
|
|
|
|
|
bool coin();
|
|
|
|
|
|
|
|
|
|
int *getIntPtr();
|
|
|
|
|
|
|
|
|
|
int *conjurePointer() {
|
2019-08-14 17:39:38 +08:00
|
|
|
int *i = getIntPtr();
|
|
|
|
|
return i;
|
2019-08-14 07:22:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void f(int *ptr) {
|
2019-08-22 04:43:27 +08:00
|
|
|
if (ptr) // expected-note-re{{{{^}}Assuming 'ptr' is null{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking false branch{{$}}}}
|
2019-08-14 07:22:33 +08:00
|
|
|
;
|
|
|
|
|
if (!conjurePointer())
|
2019-08-22 04:43:27 +08:00
|
|
|
// debug-note-re@-1{{{{^}}Tracking condition '!conjurePointer()'{{$}}}}
|
|
|
|
|
// expected-note-re@-2{{{{^}}Assuming the condition is true{{$}}}}
|
|
|
|
|
// expected-note-re@-3{{{{^}}Taking true branch{{$}}}}
|
2019-08-14 07:22:33 +08:00
|
|
|
*ptr = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
} // end of namespace unimportant_returning_pointer_loaded_from
|
|
|
|
|
|
|
|
|
|
namespace unimportant_returning_pointer_loaded_from_through_cast {
|
|
|
|
|
|
|
|
|
|
void *conjure();
|
|
|
|
|
|
|
|
|
|
int *cast(void *P) {
|
|
|
|
|
return static_cast<int *>(P);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void f() {
|
2019-08-22 04:43:27 +08:00
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
2019-08-14 07:22:33 +08:00
|
|
|
|
|
|
|
|
if (cast(conjure()))
|
2019-08-22 04:43:27 +08:00
|
|
|
// debug-note-re@-1{{{{^}}Tracking condition 'cast(conjure())'{{$}}}}
|
|
|
|
|
// expected-note-re@-2{{{{^}}Assuming the condition is false{{$}}}}
|
|
|
|
|
// expected-note-re@-3{{{{^}}Taking false branch{{$}}}}
|
2019-08-14 07:22:33 +08:00
|
|
|
return;
|
|
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
} // end of namespace unimportant_returning_pointer_loaded_from_through_cast
|
|
|
|
|
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
namespace unimportant_returning_value_note {
|
|
|
|
|
bool coin();
|
|
|
|
|
|
2019-08-14 07:22:33 +08:00
|
|
|
bool flipCoin() { return coin(); }
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
|
|
|
|
|
void i(int *ptr) {
|
2019-08-22 04:43:27 +08:00
|
|
|
if (ptr) // expected-note-re{{{{^}}Assuming 'ptr' is null{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking false branch{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
;
|
|
|
|
|
if (!flipCoin())
|
2019-08-22 04:43:27 +08:00
|
|
|
// debug-note-re@-1{{{{^}}Tracking condition '!flipCoin()'{{$}}}}
|
|
|
|
|
// expected-note-re@-2{{{{^}}Assuming the condition is true{{$}}}}
|
|
|
|
|
// expected-note-re@-3{{{{^}}Taking true branch{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
*ptr = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
} // end of namespace unimportant_returning_value_note
|
|
|
|
|
|
|
|
|
|
namespace important_returning_value_note {
|
|
|
|
|
bool coin();
|
|
|
|
|
|
|
|
|
|
bool flipCoin() {
|
2019-08-22 04:43:27 +08:00
|
|
|
if (coin()) // tracking-note-re{{{{^}}Assuming the condition is false{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Taking false branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'coin()'{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
return true;
|
2019-08-22 04:43:27 +08:00
|
|
|
return coin(); // tracking-note-re{{{{^}}Returning value, which participates in a condition later{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void i(int *ptr) {
|
2019-08-22 04:43:27 +08:00
|
|
|
if (ptr) // expected-note-re{{{{^}}Assuming 'ptr' is null{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking false branch{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
;
|
|
|
|
|
if (!flipCoin())
|
2019-08-22 04:43:27 +08:00
|
|
|
// tracking-note-re@-1{{{{^}}Calling 'flipCoin'{{$}}}}
|
|
|
|
|
// tracking-note-re@-2{{{{^}}Returning from 'flipCoin'{{$}}}}
|
|
|
|
|
// debug-note-re@-3{{{{^}}Tracking condition '!flipCoin()'{{$}}}}
|
|
|
|
|
// expected-note-re@-4{{{{^}}Assuming the condition is true{{$}}}}
|
|
|
|
|
// expected-note-re@-5{{{{^}}Taking true branch{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
*ptr = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
} // end of namespace important_returning_value_note
|
|
|
|
|
|
2019-08-14 07:22:33 +08:00
|
|
|
namespace important_returning_value_note_in_linear_function {
|
|
|
|
|
bool coin();
|
|
|
|
|
|
|
|
|
|
struct super_complicated_template_hackery {
|
|
|
|
|
static constexpr bool value = false;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
bool flipCoin() {
|
|
|
|
|
if (super_complicated_template_hackery::value)
|
2019-08-22 04:43:27 +08:00
|
|
|
// tracking-note-re@-1{{{{^}}'value' is false{{$}}}}
|
|
|
|
|
// tracking-note-re@-2{{{{^}}Taking false branch{{$}}}}
|
2019-08-14 07:22:33 +08:00
|
|
|
return true;
|
2019-08-22 04:43:27 +08:00
|
|
|
return coin(); // tracking-note-re{{{{^}}Returning value, which participates in a condition later{{$}}}}
|
2019-08-14 07:22:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void i(int *ptr) {
|
2019-08-22 04:43:27 +08:00
|
|
|
if (ptr) // expected-note-re{{{{^}}Assuming 'ptr' is null{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking false branch{{$}}}}
|
2019-08-14 07:22:33 +08:00
|
|
|
;
|
|
|
|
|
if (!flipCoin())
|
2019-08-22 04:43:27 +08:00
|
|
|
// tracking-note-re@-1{{{{^}}Calling 'flipCoin'{{$}}}}
|
|
|
|
|
// tracking-note-re@-2{{{{^}}Returning from 'flipCoin'{{$}}}}
|
|
|
|
|
// debug-note-re@-3{{{{^}}Tracking condition '!flipCoin()'{{$}}}}
|
|
|
|
|
// expected-note-re@-4{{{{^}}Assuming the condition is true{{$}}}}
|
|
|
|
|
// expected-note-re@-5{{{{^}}Taking true branch{{$}}}}
|
2019-08-14 07:22:33 +08:00
|
|
|
*ptr = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
} // end of namespace important_returning_value_note_in_linear_function
|
|
|
|
|
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
namespace tracked_condition_is_only_initialized {
|
|
|
|
|
int getInt();
|
|
|
|
|
|
|
|
|
|
void f() {
|
2019-08-14 17:39:38 +08:00
|
|
|
int flag = getInt();
|
2019-08-22 04:43:27 +08:00
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
|
|
|
|
if (flag) // expected-note-re{{{{^}}Assuming 'flag' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
} // end of namespace tracked_condition_is_only_initialized
|
|
|
|
|
|
|
|
|
|
namespace tracked_condition_written_in_same_stackframe {
|
|
|
|
|
int flag;
|
|
|
|
|
int getInt();
|
|
|
|
|
|
|
|
|
|
void f(int y) {
|
2019-08-14 17:39:38 +08:00
|
|
|
y = 1;
|
|
|
|
|
flag = y;
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
|
2019-08-22 04:43:27 +08:00
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
|
|
|
|
if (flag) // expected-note-re{{{{^}}'flag' is 1{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
} // end of namespace tracked_condition_written_in_same_stackframe
|
|
|
|
|
|
|
|
|
|
namespace tracked_condition_written_in_nested_stackframe {
|
|
|
|
|
int flag;
|
|
|
|
|
int getInt();
|
|
|
|
|
|
|
|
|
|
void foo() {
|
|
|
|
|
int y;
|
2019-08-14 17:39:38 +08:00
|
|
|
y = 1;
|
2019-08-22 04:43:27 +08:00
|
|
|
flag = y; // tracking-note-re{{{{^}}The value 1 is assigned to 'flag', which participates in a condition later{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void f(int y) {
|
2019-08-22 04:43:27 +08:00
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
|
2019-08-22 04:43:27 +08:00
|
|
|
foo(); // tracking-note-re{{{{^}}Calling 'foo'{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Returning from 'foo'{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
|
2019-08-22 04:43:27 +08:00
|
|
|
if (flag) // expected-note-re{{{{^}}'flag' is 1{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
} // end of namespace tracked_condition_written_in_nested_stackframe
|
|
|
|
|
|
2019-08-14 07:48:10 +08:00
|
|
|
namespace condition_written_in_nested_stackframe_before_assignment {
|
|
|
|
|
int flag = 0;
|
|
|
|
|
int getInt();
|
|
|
|
|
|
|
|
|
|
void foo() {
|
2019-08-22 04:43:27 +08:00
|
|
|
flag = getInt(); // tracking-note-re{{{{^}}Value assigned to 'flag', which participates in a condition later{{$}}}}
|
2019-08-14 07:48:10 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void f() {
|
2019-08-22 04:43:27 +08:00
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
2019-08-14 07:48:10 +08:00
|
|
|
int y = 0;
|
|
|
|
|
|
2019-08-22 04:43:27 +08:00
|
|
|
foo(); // tracking-note-re{{{{^}}Calling 'foo'{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Returning from 'foo'{{$}}}}
|
2019-08-14 17:39:38 +08:00
|
|
|
y = flag;
|
2019-08-14 07:48:10 +08:00
|
|
|
|
2019-08-22 04:43:27 +08:00
|
|
|
if (y) // expected-note-re{{{{^}}Assuming 'y' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'y'{{$}}}}
|
2019-08-14 07:48:10 +08:00
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
} // end of namespace condition_written_in_nested_stackframe_before_assignment
|
|
|
|
|
|
2019-08-22 10:44:19 +08:00
|
|
|
namespace dont_explain_foreach_loops {
|
|
|
|
|
|
|
|
|
|
struct Iterator {
|
|
|
|
|
int *pos;
|
|
|
|
|
bool operator!=(Iterator other) const {
|
|
|
|
|
return pos && other.pos && pos != other.pos;
|
|
|
|
|
}
|
|
|
|
|
int operator*();
|
|
|
|
|
Iterator operator++();
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct Container {
|
|
|
|
|
Iterator begin();
|
|
|
|
|
Iterator end();
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
void f(Container Cont) {
|
|
|
|
|
int flag = 0;
|
|
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
|
|
|
|
for (int i : Cont)
|
|
|
|
|
if (i) // expected-note-re {{{{^}}Assuming 'i' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'i'{{$}}}}
|
|
|
|
|
flag = i;
|
|
|
|
|
|
|
|
|
|
if (flag) // expected-note-re{{{{^}}'flag' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
|
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
} // end of namespace dont_explain_foreach_loops
|
|
|
|
|
|
2019-08-22 05:59:22 +08:00
|
|
|
namespace condition_lambda_capture_by_reference_last_write {
|
|
|
|
|
int getInt();
|
|
|
|
|
|
|
|
|
|
[[noreturn]] void halt();
|
|
|
|
|
|
|
|
|
|
void f(int flag) {
|
|
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
|
|
|
|
|
|
|
|
|
auto lambda = [&flag]() {
|
|
|
|
|
flag = getInt(); // tracking-note-re{{{{^}}Value assigned to 'flag', which participates in a condition later{{$}}}}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
lambda(); // tracking-note-re{{{{^}}Calling 'operator()'{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Returning from 'operator()'{{$}}}}
|
|
|
|
|
|
|
|
|
|
if (flag) // expected-note-re{{{{^}}Assuming 'flag' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
|
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
} // end of namespace condition_lambda_capture_by_reference_last_write
|
|
|
|
|
|
|
|
|
|
namespace condition_lambda_capture_by_value_assumption {
|
|
|
|
|
int getInt();
|
|
|
|
|
|
|
|
|
|
[[noreturn]] void halt();
|
|
|
|
|
|
|
|
|
|
void bar(int &flag) {
|
|
|
|
|
flag = getInt(); // tracking-note-re{{{{^}}Value assigned to 'flag', which participates in a condition later{{$}}}}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void f(int flag) {
|
|
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
|
|
|
|
|
|
|
|
|
auto lambda = [flag]() {
|
2019-08-22 06:38:00 +08:00
|
|
|
if (!flag) // tracking-note-re{{{{^}}Assuming 'flag' is not equal to 0, which participates in a condition later{{$}}}}
|
2019-08-22 05:59:22 +08:00
|
|
|
// tracking-note-re@-1{{{{^}}Taking false branch{{$}}}}
|
|
|
|
|
halt();
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
bar(flag); // tracking-note-re{{{{^}}Calling 'bar'{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Returning from 'bar'{{$}}}}
|
|
|
|
|
lambda(); // tracking-note-re{{{{^}}Calling 'operator()'{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Returning from 'operator()'{{$}}}}
|
|
|
|
|
|
|
|
|
|
if (flag) // expected-note-re{{{{^}}Assuming 'flag' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
|
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
} // end of namespace condition_lambda_capture_by_value_assumption
|
|
|
|
|
|
|
|
|
|
namespace condition_lambda_capture_by_reference_assumption {
|
|
|
|
|
int getInt();
|
|
|
|
|
|
|
|
|
|
[[noreturn]] void halt();
|
|
|
|
|
|
|
|
|
|
void bar(int &flag) {
|
|
|
|
|
flag = getInt(); // tracking-note-re{{{{^}}Value assigned to 'flag', which participates in a condition later{{$}}}}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void f(int flag) {
|
|
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
|
|
|
|
|
|
|
|
|
auto lambda = [&flag]() {
|
2019-08-22 06:38:00 +08:00
|
|
|
if (!flag) // tracking-note-re{{{{^}}Assuming 'flag' is not equal to 0, which participates in a condition later{{$}}}}
|
2019-08-22 05:59:22 +08:00
|
|
|
// tracking-note-re@-1{{{{^}}Taking false branch{{$}}}}
|
|
|
|
|
halt();
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
bar(flag); // tracking-note-re{{{{^}}Calling 'bar'{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Returning from 'bar'{{$}}}}
|
|
|
|
|
lambda(); // tracking-note-re{{{{^}}Calling 'operator()'{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Returning from 'operator()'{{$}}}}
|
|
|
|
|
|
|
|
|
|
if (flag) // expected-note-re{{{{^}}'flag' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
2019-08-22 06:38:00 +08:00
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
2019-08-22 05:59:22 +08:00
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
} // end of namespace condition_lambda_capture_by_reference_assumption
|
|
|
|
|
|
2019-08-22 06:38:00 +08:00
|
|
|
namespace collapse_point_not_in_condition_bool {
|
|
|
|
|
|
|
|
|
|
[[noreturn]] void halt();
|
|
|
|
|
|
|
|
|
|
void check(bool b) {
|
|
|
|
|
if (!b) // tracking-note-re{{{{^}}Assuming 'b' is true, which participates in a condition later{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Taking false branch{{$}}}}
|
|
|
|
|
halt();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void f(bool flag) {
|
|
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
|
|
|
|
|
|
|
|
|
check(flag); // tracking-note-re{{{{^}}Calling 'check'{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Returning from 'check'{{$}}}}
|
|
|
|
|
|
|
|
|
|
if (flag) // expected-note-re{{{{^}}'flag' is true{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
|
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
} // end of namespace collapse_point_not_in_condition_bool
|
|
|
|
|
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
namespace collapse_point_not_in_condition {
|
|
|
|
|
|
|
|
|
|
[[noreturn]] void halt();
|
|
|
|
|
|
|
|
|
|
void assert(int b) {
|
2019-08-22 06:38:00 +08:00
|
|
|
if (!b) // tracking-note-re{{{{^}}Assuming 'b' is not equal to 0, which participates in a condition later{{$}}}}
|
2019-08-22 04:43:27 +08:00
|
|
|
// tracking-note-re@-1{{{{^}}Taking false branch{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
halt();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void f(int flag) {
|
2019-08-22 04:43:27 +08:00
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
|
2019-08-22 04:43:27 +08:00
|
|
|
assert(flag); // tracking-note-re{{{{^}}Calling 'assert'{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Returning from 'assert'{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
|
2019-08-22 04:43:27 +08:00
|
|
|
if (flag) // expected-note-re{{{{^}}'flag' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
} // end of namespace collapse_point_not_in_condition
|
|
|
|
|
|
|
|
|
|
namespace unimportant_write_before_collapse_point {
|
|
|
|
|
|
|
|
|
|
[[noreturn]] void halt();
|
|
|
|
|
|
|
|
|
|
void assert(int b) {
|
2019-08-22 06:38:00 +08:00
|
|
|
if (!b) // tracking-note-re{{{{^}}Assuming 'b' is not equal to 0, which participates in a condition later{{$}}}}
|
2019-08-22 04:43:27 +08:00
|
|
|
// tracking-note-re@-1{{{{^}}Taking false branch{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
halt();
|
|
|
|
|
}
|
|
|
|
|
int getInt();
|
|
|
|
|
|
|
|
|
|
void f(int flag) {
|
2019-08-22 04:43:27 +08:00
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
|
2019-08-14 17:39:38 +08:00
|
|
|
flag = getInt();
|
2019-08-22 04:43:27 +08:00
|
|
|
assert(flag); // tracking-note-re{{{{^}}Calling 'assert'{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Returning from 'assert'{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
|
2019-08-22 04:43:27 +08:00
|
|
|
if (flag) // expected-note-re{{{{^}}'flag' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
[analyzer] Track terminator conditions on which a tracked expression depends
This patch is a major part of my GSoC project, aimed to improve the bug
reports of the analyzer.
TL;DR: Help the analyzer understand that some conditions are important,
and should be explained better. If an CFGBlock is a control dependency
of a block where an expression value is tracked, explain the condition
expression better by tracking it.
if (A) // let's explain why we believe A to be true
10 / x; // division by zero
This is an experimental feature, and can be enabled by the
off-by-default analyzer configuration "track-conditions".
In detail:
This idea was inspired by the program slicing algorithm. Essentially,
two things are used to produce a program slice (a subset of the program
relevant to a (statement, variable) pair): data and control
dependencies. The bug path (the linear path in the ExplodedGraph that leads
from the beginning of the analysis to the error node) enables to
analyzer to argue about data dependencies with relative ease.
Control dependencies are a different slice of the cake entirely.
Just because we reached a branch during symbolic execution, it
doesn't mean that that particular branch has any effect on whether the
bug would've occured. This means that we can't simply rely on the bug
path to gather control dependencies.
In previous patches, LLVM's IDFCalculator, which works on a control flow
graph rather than the ExplodedGraph was generalized to solve this issue.
We use this information to heuristically guess that the value of a tracked
expression depends greatly on it's control dependencies, and start
tracking them as well.
After plenty of evaluations this was seen as great idea, but still
lacking refinements (we should have different descriptions about a
conditions value), hence it's off-by-default.
Differential Revision: https://reviews.llvm.org/D62883
llvm-svn: 365207
2019-07-05 21:29:54 +08:00
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
} // end of namespace unimportant_write_before_collapse_point
|
2019-08-14 20:20:08 +08:00
|
|
|
|
2019-08-18 00:49:54 +08:00
|
|
|
namespace dont_crash_on_nonlogical_binary_operator {
|
|
|
|
|
|
|
|
|
|
void f6(int x) {
|
|
|
|
|
int a[20];
|
|
|
|
|
if (x == 25) {} // expected-note{{Assuming 'x' is equal to 25}}
|
|
|
|
|
// expected-note@-1{{Taking true branch}}
|
|
|
|
|
if (a[x] == 123) {} // expected-warning{{The left operand of '==' is a garbage value due to array index out of bounds}}
|
|
|
|
|
// expected-note@-1{{The left operand of '==' is a garbage value due to array index out of bounds}}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
} // end of namespace dont_crash_on_nonlogical_binary_operator
|
|
|
|
|
|
2019-08-22 06:38:00 +08:00
|
|
|
namespace collapse_point_not_in_condition_binary_op {
|
|
|
|
|
|
|
|
|
|
[[noreturn]] void halt();
|
|
|
|
|
|
|
|
|
|
void check(int b) {
|
|
|
|
|
if (b == 1) // tracking-note-re{{{{^}}Assuming 'b' is not equal to 1, which participates in a condition later{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Taking false branch{{$}}}}
|
|
|
|
|
halt();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void f(int flag) {
|
|
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
|
|
|
|
|
|
|
|
|
check(flag); // tracking-note-re{{{{^}}Calling 'check'{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Returning from 'check'{{$}}}}
|
|
|
|
|
|
|
|
|
|
if (flag) // expected-note-re{{{{^}}Assuming 'flag' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
|
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
} // end of namespace collapse_point_not_in_condition_binary_op
|
|
|
|
|
|
2019-08-22 05:59:22 +08:00
|
|
|
namespace collapse_point_not_in_condition_as_field {
|
|
|
|
|
|
|
|
|
|
[[noreturn]] void halt();
|
|
|
|
|
struct IntWrapper {
|
|
|
|
|
int b;
|
|
|
|
|
IntWrapper();
|
|
|
|
|
|
|
|
|
|
void check() {
|
2019-08-22 06:38:00 +08:00
|
|
|
if (!b) // tracking-note-re{{{{^}}Assuming field 'b' is not equal to 0, which participates in a condition later{{$}}}}
|
2019-08-22 05:59:22 +08:00
|
|
|
// tracking-note-re@-1{{{{^}}Taking false branch{{$}}}}
|
|
|
|
|
halt();
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
void f(IntWrapper i) {
|
|
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
|
|
|
|
|
|
|
|
|
i.check(); // tracking-note-re{{{{^}}Calling 'IntWrapper::check'{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Returning from 'IntWrapper::check'{{$}}}}
|
|
|
|
|
if (i.b) // expected-note-re{{{{^}}Field 'b' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'i.b'{{$}}}}
|
|
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
} // end of namespace collapse_point_not_in_condition_as_field
|
|
|
|
|
|
2019-08-22 06:38:00 +08:00
|
|
|
namespace assignemnt_in_condition_in_nested_stackframe {
|
|
|
|
|
int flag;
|
|
|
|
|
|
|
|
|
|
bool coin();
|
|
|
|
|
|
|
|
|
|
[[noreturn]] void halt();
|
|
|
|
|
|
|
|
|
|
void foo() {
|
|
|
|
|
if ((flag = coin()))
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Value assigned to 'flag', which participates in a condition later{{$}}}}
|
|
|
|
|
// tracking-note-re@-2{{{{^}}Assuming 'flag' is not equal to 0, which participates in a condition later{{$}}}}
|
|
|
|
|
// tracking-note-re@-3{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
return;
|
|
|
|
|
halt();
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void f() {
|
|
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
|
|
|
|
|
|
|
|
|
foo(); // tracking-note-re{{{{^}}Calling 'foo'{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Returning from 'foo'{{$}}}}
|
|
|
|
|
if (flag) // expected-note-re{{{{^}}'flag' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
|
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
} // end of namespace assignemnt_in_condition_in_nested_stackframe
|
|
|
|
|
|
|
|
|
|
namespace condition_variable_less {
|
|
|
|
|
int flag;
|
|
|
|
|
|
|
|
|
|
bool coin();
|
|
|
|
|
|
|
|
|
|
[[noreturn]] void halt();
|
|
|
|
|
|
|
|
|
|
void foo() {
|
|
|
|
|
if (flag > 0)
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Assuming 'flag' is > 0, which participates in a condition later{{$}}}}
|
|
|
|
|
// tracking-note-re@-2{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
return;
|
|
|
|
|
halt();
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void f() {
|
|
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
|
|
|
|
|
|
|
|
|
foo(); // tracking-note-re{{{{^}}Calling 'foo'{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Returning from 'foo'{{$}}}}
|
|
|
|
|
if (flag) // expected-note-re{{{{^}}'flag' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
|
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
} // end of namespace condition_variable_less
|
|
|
|
|
|
2019-08-14 20:20:08 +08:00
|
|
|
namespace dont_track_assertlike_conditions {
|
|
|
|
|
|
|
|
|
|
extern void __assert_fail(__const char *__assertion, __const char *__file,
|
|
|
|
|
unsigned int __line, __const char *__function)
|
|
|
|
|
__attribute__((__noreturn__));
|
|
|
|
|
#define assert(expr) \
|
|
|
|
|
((expr) ? (void)(0) : __assert_fail(#expr, __FILE__, __LINE__, __func__))
|
|
|
|
|
|
|
|
|
|
int getInt();
|
|
|
|
|
|
|
|
|
|
int cond1;
|
|
|
|
|
|
|
|
|
|
void bar() {
|
|
|
|
|
cond1 = getInt();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void f(int flag) {
|
2019-08-22 04:43:27 +08:00
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
2019-08-14 20:20:08 +08:00
|
|
|
|
|
|
|
|
flag = getInt();
|
|
|
|
|
|
|
|
|
|
bar();
|
2019-08-22 04:43:27 +08:00
|
|
|
assert(cond1); // expected-note-re{{{{^}}Assuming 'cond1' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}'?' condition is true{{$}}}}
|
2019-08-14 20:20:08 +08:00
|
|
|
|
2019-08-22 04:43:27 +08:00
|
|
|
if (flag) // expected-note-re{{{{^}}Assuming 'flag' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
2019-08-14 20:20:08 +08:00
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#undef assert
|
|
|
|
|
} // end of namespace dont_track_assertlike_conditions
|
|
|
|
|
|
|
|
|
|
namespace dont_track_assertlike_and_conditions {
|
|
|
|
|
|
|
|
|
|
extern void __assert_fail(__const char *__assertion, __const char *__file,
|
|
|
|
|
unsigned int __line, __const char *__function)
|
|
|
|
|
__attribute__((__noreturn__));
|
|
|
|
|
#define assert(expr) \
|
|
|
|
|
((expr) ? (void)(0) : __assert_fail(#expr, __FILE__, __LINE__, __func__))
|
|
|
|
|
|
|
|
|
|
int getInt();
|
|
|
|
|
|
|
|
|
|
int cond1;
|
|
|
|
|
int cond2;
|
|
|
|
|
|
|
|
|
|
void bar() {
|
|
|
|
|
cond1 = getInt();
|
|
|
|
|
cond2 = getInt();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void f(int flag) {
|
2019-08-22 04:43:27 +08:00
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
2019-08-14 20:20:08 +08:00
|
|
|
|
|
|
|
|
flag = getInt();
|
|
|
|
|
|
|
|
|
|
bar();
|
|
|
|
|
assert(cond1 && cond2);
|
2019-08-22 04:43:27 +08:00
|
|
|
// expected-note-re@-1{{{{^}}Assuming 'cond1' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-2{{{{^}}Assuming 'cond2' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-3{{{{^}}'?' condition is true{{$}}}}
|
|
|
|
|
// expected-note-re@-4{{{{^}}Left side of '&&' is true{{$}}}}
|
|
|
|
|
|
|
|
|
|
if (flag) // expected-note-re{{{{^}}Assuming 'flag' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
2019-08-14 20:20:08 +08:00
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#undef assert
|
|
|
|
|
} // end of namespace dont_track_assertlike_and_conditions
|
|
|
|
|
|
|
|
|
|
namespace dont_track_assertlike_or_conditions {
|
|
|
|
|
|
|
|
|
|
extern void __assert_fail(__const char *__assertion, __const char *__file,
|
|
|
|
|
unsigned int __line, __const char *__function)
|
|
|
|
|
__attribute__((__noreturn__));
|
|
|
|
|
#define assert(expr) \
|
|
|
|
|
((expr) ? (void)(0) : __assert_fail(#expr, __FILE__, __LINE__, __func__))
|
|
|
|
|
|
|
|
|
|
int getInt();
|
|
|
|
|
|
|
|
|
|
int cond1;
|
|
|
|
|
int cond2;
|
|
|
|
|
|
|
|
|
|
void bar() {
|
|
|
|
|
cond1 = getInt();
|
|
|
|
|
cond2 = getInt();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void f(int flag) {
|
2019-08-22 04:43:27 +08:00
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
2019-08-14 20:20:08 +08:00
|
|
|
|
|
|
|
|
flag = getInt();
|
|
|
|
|
|
|
|
|
|
bar();
|
|
|
|
|
assert(cond1 || cond2);
|
2019-08-22 04:43:27 +08:00
|
|
|
// expected-note-re@-1{{{{^}}Assuming 'cond1' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-2{{{{^}}Left side of '||' is true{{$}}}}
|
2019-08-14 20:20:08 +08:00
|
|
|
|
2019-08-22 04:43:27 +08:00
|
|
|
if (flag) // expected-note-re{{{{^}}Assuming 'flag' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
2019-08-14 20:20:08 +08:00
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#undef assert
|
|
|
|
|
} // end of namespace dont_track_assertlike_or_conditions
|
|
|
|
|
|
|
|
|
|
namespace dont_track_assert2like_conditions {
|
|
|
|
|
|
|
|
|
|
extern void __assert_fail(__const char *__assertion, __const char *__file,
|
|
|
|
|
unsigned int __line, __const char *__function)
|
|
|
|
|
__attribute__((__noreturn__));
|
|
|
|
|
#define assert(expr) \
|
|
|
|
|
do { \
|
|
|
|
|
if (!(expr)) \
|
|
|
|
|
__assert_fail(#expr, __FILE__, __LINE__, __func__); \
|
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
|
|
int getInt();
|
|
|
|
|
|
|
|
|
|
int cond1;
|
|
|
|
|
|
|
|
|
|
void bar() {
|
|
|
|
|
cond1 = getInt();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void f(int flag) {
|
2019-08-22 04:43:27 +08:00
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
2019-08-14 20:20:08 +08:00
|
|
|
|
|
|
|
|
flag = getInt();
|
|
|
|
|
|
|
|
|
|
bar();
|
2019-08-22 04:43:27 +08:00
|
|
|
assert(cond1); // expected-note-re{{{{^}}Assuming 'cond1' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking false branch{{$}}}}
|
|
|
|
|
// expected-note-re@-2{{{{^}}Loop condition is false. Exiting loop{{$}}}}
|
2019-08-14 20:20:08 +08:00
|
|
|
|
2019-08-22 04:43:27 +08:00
|
|
|
if (flag) // expected-note-re{{{{^}}Assuming 'flag' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
2019-08-14 20:20:08 +08:00
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#undef assert
|
|
|
|
|
} // end of namespace dont_track_assert2like_conditions
|
|
|
|
|
|
|
|
|
|
namespace dont_track_assert2like_and_conditions {
|
|
|
|
|
|
|
|
|
|
extern void __assert_fail(__const char *__assertion, __const char *__file,
|
|
|
|
|
unsigned int __line, __const char *__function)
|
|
|
|
|
__attribute__((__noreturn__));
|
|
|
|
|
#define assert(expr) \
|
|
|
|
|
do { \
|
|
|
|
|
if (!(expr)) \
|
|
|
|
|
__assert_fail(#expr, __FILE__, __LINE__, __func__); \
|
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
|
|
int getInt();
|
|
|
|
|
|
|
|
|
|
int cond1;
|
|
|
|
|
int cond2;
|
|
|
|
|
|
|
|
|
|
void bar() {
|
|
|
|
|
cond1 = getInt();
|
|
|
|
|
cond2 = getInt();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void f(int flag) {
|
2019-08-22 04:43:27 +08:00
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
2019-08-14 20:20:08 +08:00
|
|
|
|
|
|
|
|
flag = getInt();
|
|
|
|
|
|
|
|
|
|
bar();
|
|
|
|
|
assert(cond1 && cond2);
|
2019-08-22 04:43:27 +08:00
|
|
|
// expected-note-re@-1{{{{^}}Assuming 'cond1' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-2{{{{^}}Left side of '&&' is true{{$}}}}
|
|
|
|
|
// expected-note-re@-3{{{{^}}Assuming the condition is false{{$}}}}
|
|
|
|
|
// expected-note-re@-4{{{{^}}Taking false branch{{$}}}}
|
|
|
|
|
// expected-note-re@-5{{{{^}}Loop condition is false. Exiting loop{{$}}}}
|
|
|
|
|
|
|
|
|
|
if (flag) // expected-note-re{{{{^}}Assuming 'flag' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
2019-08-14 20:20:08 +08:00
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#undef assert
|
|
|
|
|
} // end of namespace dont_track_assert2like_and_conditions
|
|
|
|
|
|
|
|
|
|
namespace dont_track_assert2like_or_conditions {
|
|
|
|
|
|
|
|
|
|
extern void __assert_fail(__const char *__assertion, __const char *__file,
|
|
|
|
|
unsigned int __line, __const char *__function)
|
|
|
|
|
__attribute__((__noreturn__));
|
|
|
|
|
#define assert(expr) \
|
|
|
|
|
do { \
|
|
|
|
|
if (!(expr)) \
|
|
|
|
|
__assert_fail(#expr, __FILE__, __LINE__, __func__); \
|
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
|
|
int getInt();
|
|
|
|
|
|
|
|
|
|
int cond1;
|
|
|
|
|
int cond2;
|
|
|
|
|
|
|
|
|
|
void bar() {
|
|
|
|
|
cond1 = getInt();
|
|
|
|
|
cond2 = getInt();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void f(int flag) {
|
2019-08-22 04:43:27 +08:00
|
|
|
int *x = 0; // expected-note-re{{{{^}}'x' initialized to a null pointer value{{$}}}}
|
2019-08-14 20:20:08 +08:00
|
|
|
|
|
|
|
|
flag = getInt();
|
|
|
|
|
|
|
|
|
|
bar();
|
|
|
|
|
assert(cond1 || cond2);
|
2019-08-22 04:43:27 +08:00
|
|
|
// expected-note-re@-1{{{{^}}Assuming 'cond1' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-2{{{{^}}Left side of '||' is true{{$}}}}
|
|
|
|
|
// expected-note-re@-3{{{{^}}Taking false branch{{$}}}}
|
|
|
|
|
// expected-note-re@-4{{{{^}}Loop condition is false. Exiting loop{{$}}}}
|
|
|
|
|
|
|
|
|
|
if (flag) // expected-note-re{{{{^}}Assuming 'flag' is not equal to 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Taking true branch{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
2019-08-14 20:20:08 +08:00
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#undef assert
|
|
|
|
|
} // end of namespace dont_track_assert2like_or_conditions
|
2019-08-14 21:51:52 +08:00
|
|
|
|
|
|
|
|
namespace only_track_the_evaluated_condition {
|
|
|
|
|
|
|
|
|
|
bool coin();
|
|
|
|
|
|
|
|
|
|
void bar(int &flag) {
|
2019-08-22 04:43:27 +08:00
|
|
|
flag = coin(); // tracking-note-re{{{{^}}Value assigned to 'flag', which participates in a condition later{{$}}}}
|
2019-08-14 21:51:52 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void bar2(int &flag2) {
|
|
|
|
|
flag2 = coin();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void f(int *x) {
|
2019-08-22 04:43:27 +08:00
|
|
|
if (x) // expected-note-re{{{{^}}Assuming 'x' is null{{$}}}}
|
|
|
|
|
// debug-note-re@-1{{{{^}}Tracking condition 'x'{{$}}}}
|
|
|
|
|
// expected-note-re@-2{{{{^}}Taking false branch{{$}}}}
|
2019-08-14 21:51:52 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
int flag, flag2;
|
2019-08-22 04:43:27 +08:00
|
|
|
bar(flag); // tracking-note-re{{{{^}}Calling 'bar'{{$}}}}
|
|
|
|
|
// tracking-note-re@-1{{{{^}}Returning from 'bar'{{$}}}}
|
2019-08-14 21:51:52 +08:00
|
|
|
bar2(flag2);
|
|
|
|
|
|
2019-08-22 04:43:27 +08:00
|
|
|
if (flag && flag2) // expected-note-re {{{{^}}Assuming 'flag' is 0{{$}}}}
|
|
|
|
|
// expected-note-re@-1{{{{^}}Left side of '&&' is false{{$}}}}
|
|
|
|
|
// debug-note-re@-2{{{{^}}Tracking condition 'flag'{{$}}}}
|
2019-08-14 21:51:52 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
*x = 5; // expected-warning{{Dereference of null pointer}}
|
|
|
|
|
// expected-note@-1{{Dereference of null pointer}}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
} // end of namespace only_track_the_evaluated_condition
|