This only affects the cfg-temporary-dtors mode - in this mode we begin inlining
constructors that are constructing function return values. These constructors
have a correct construction context since r324952.
Because temporary destructors are not only never inlined, but also don't have
the correct target region yet, this change is not entirely safe. But this
will be fixed in the subsequent commits, while this stays off behind the
cfg-temporary-dtors flag.
Lifetime extension for return values is still not modeled correctly.
Differential Revision: https://reviews.llvm.org/D42875
llvm-svn: 325202
See reviews.llvm.org/M1 for evaluation, and
lists.llvm.org/pipermail/cfe-dev/2018-January/056718.html for
discussion.
Differential Revision: https://reviews.llvm.org/D42775
llvm-svn: 324956
When the current function returns a C++ object by value, CFG elements for
constructors that construct the return values can now be queried to discover
that they're indeed participating in construction of the respective return value
at the respective return statement.
Differential Revision: https://reviews.llvm.org/D42875
llvm-svn: 324952
It was introduced when two -analyzer-config options were added almost
simultaneously in r324793 and r324668 and the option count was not
rebased correctly in the tests.
Fixes the buildbots.
llvm-svn: 324801
Now that we make it possible to query the CFG constructor element to find
information about the construction site, possible cleanup work represented by
ExprWithCleanups should not prevent us from providing this information.
This allows us to have a correct construction context for variables initialized
"by value" via elidable copy-constructors, such as 'i' in
iterator i = vector.begin();
Differential Revision: https://reviews.llvm.org/D42719
llvm-svn: 324798
CFG elements for constructors of fields and base classes that are being
initialized before the body of the whole-class constructor starts can now be
queried to discover that they're indeed participating in initialization of their
respective fields or bases before the whole-class constructor kicks in.
CFG construction contexts are now capable of representing CXXCtorInitializer
triggers, which aren't considered to be statements in the Clang AST.
Differential Revision: https://reviews.llvm.org/D42700
llvm-svn: 324796
Constructors of simple variables now can be queried to discover that they're
constructing into simple variables.
Differential Revision: https://reviews.llvm.org/D42699
llvm-svn: 324794
This expression may or may not be evaluated in compile time, so tracking the
result symbol is of potential interest. However, run-time offsetof is not yet
supported by the analyzer, so for now this callback is only there to assist
future implementation.
Patch by Henry Wong!
Differential Revision: https://reviews.llvm.org/D42300
llvm-svn: 324790
This builtin is evaluated in compile time. But in the analyzer we don't yet
automagically evaluate all calls that can be evaluated in compile time.
Patch by Felix Kostenzer!
Differential Revision: https://reviews.llvm.org/D42745
llvm-svn: 324789
Even though most of the inconsistencies in MallocChecker's bug categories were
fixed in r302016, one more was introduced in r301913 which was later missed.
Patch by Henry Wong!
Differential Revision: https://reviews.llvm.org/D43074
llvm-svn: 324680
This patch adds a new CFGStmt sub-class, CFGConstructor, which replaces
the regular CFGStmt with CXXConstructExpr in it whenever the CFG has additional
information to provide regarding what sort of object is being constructed.
It is useful for figuring out what memory is initialized in client of the
CFG such as the Static Analyzer, which do not operate by recursive AST
traversal, but instead rely on the CFG to provide all the information when they
need it. Otherwise, the statement that triggers the construction and defines
what memory is being initialized would normally occur after the
construct-expression, and the client would need to peek to the next CFG element
or use statement parent map to understand the necessary facts about
the construct-expression.
As a proof of concept, CFGConstructors are added for new-expressions
and the respective test cases are provided to demonstrate how it works.
For now, the only additional data contained in the CFGConstructor element is
the "trigger statement", such as new-expression, which is the parent of the
constructor. It will be significantly expanded in later commits. The additional
data is organized as an auxiliary structure - the "construction context",
which is allocated separately from the CFGElement.
Differential Revision: https://reviews.llvm.org/D42672
llvm-svn: 324668
It makes it easier to discriminate between values of similar expressions
in different stack frames.
It also makes the separate backtrace section in ExplodedGraph dumps redundant.
Differential Revision: https://reviews.llvm.org/D42552
llvm-svn: 324660
Due to Buildbot failures - most likely that's because target triples were not
specified in the tests, even though the checker behaves differently with
different target triples.
llvm-svn: 324167
This is a security check which is disabled by default but will be enabled
whenever the user consciously enables the security package. If mmap()ed memory
is both writable and executable, it makes it easier for the attacker to execute
arbitrary code when contents of this memory are compromised. Some applications
require such mmap()s though, such as different sorts of JIT.
Patch by David Carlier!
Differential Revision: https://reviews.llvm.org/D42645
llvm-svn: 324166
We already suppress such reports for inlined functions, we should then
get the same behavior for macros.
The underlying reason is that the same macro, can be called from many
different contexts, and nullability can only be expected in _some_ of
them.
Assuming that the macro can return null in _all_ of them sometimes leads
to a large number of false positives.
E.g. consider the test case for the dynamic cast implementation in
macro: in such cases, the bug report is unwanted.
Tracked in rdar://36304776
Differential Revision: https://reviews.llvm.org/D42404
llvm-svn: 324161
If the return statement is stored, we might as well allow querying
against it.
Also fix the bug where the return statement is not stored
if there is no return value.
This change un-merges two ExplodedNodes during call exit when the state
is otherwise identical - the CallExitBegin node itself and the "Bind
Return Value"-tagged node.
And expose the return statement through
getStatement helper function.
Differential Revision: https://reviews.llvm.org/D42130
llvm-svn: 324052
We use CXXTempObjectRegion exclusively as a bailout value for construction
targets when we are unable to find the correct construction region.
Sometimes it works correctly, but rather accidentally than intentionally.
Now that we want to increase the amount of situations where it works correctly,
the first step is to introduce a different way of communicating our failure
to find the correct construction region. EvalCallOptions are introduced
for this purpose.
For now EvalCallOptions are communicating two kinds of problems:
- We have been completely unable to find the correct construction site.
- We have found the construction site correctly, and there's more than one of
them (i.e. array construction which we currently don't support).
Accidentally find and fix a test in which the new approach to communicating
failures produces better results.
Differential Revision: https://reviews.llvm.org/D42457
llvm-svn: 324018
Do not attempt to get the pointee of void* while generating a bug report
(otherwise it will trigger an assert inside RegionStoreManager::getBinding
assert(!T->isVoidType() && "Attempting to dereference a void pointer!")).
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D42396
llvm-svn: 323382
In order to provide more test coverage for inlined operator new(), add more
run-lines to existing test cases, which would trigger our fake header
to provide a body for operator new(). Most of the code should still behave
reasonably. When behavior intentionally changes, #ifs are provided.
Differential Revision: https://reviews.llvm.org/D42221
llvm-svn: 323376
This allows the analyzer to analyze ("inline") custom operator new() calls and,
even more importantly, inline constructors of objects that were allocated
by any operator new() - not necessarily a custom one.
All changes in the tests in the current commit are intended improvements,
even if they didn't carry any explicit FIXME flag.
It is possible to restore the old behavior via
-analyzer-config c++-allocator-inlining=false
(this flag is supported by scan-build as well, and it can be into a clang
--analyze invocation via -Xclang .. -Xclang ..). There is no intention to
remove the old behavior for now.
Differential Revision: https://reviews.llvm.org/D42219
rdar://problem/12180598
llvm-svn: 323373
I.e. not after. In the c++-allocator-inlining=true mode, we need to make the
assumption that the conservatively evaluated operator new() has returned a
non-null value. Previously we did this on CXXNewExpr, but now we have to do that
before calling the constructor, because some clever constructors are sometimes
assuming that their "this" is null and doing weird stuff. We would also crash
upon evaluating CXXNewExpr when the allocator was inlined and returned null and
had a throw specification; this is UB even for custom allocators, but we still
need not to crash.
Added more FIXME tests to ensure that eventually we fix calling the constructor
for null return values.
Differential Revision: https://reviews.llvm.org/D42192
llvm-svn: 323370
Fix an assertion failure caused by a missing CheckName. The malloc checker
enables "basic" support in the CStringChecker, which causes some CString
bounds checks to be enabled. In this case, make sure that we have a
valid CheckName for the BugType.
llvm-svn: 323052
PreStmt<CXXNewExpr> was never called.
Additionally, under c++-allocator-inlining=true, PostStmt<CXXNewExpr> was
called twice when the allocator was inlined: once after evaluating the
new-expression itself, once after evaluating the allocator call which, for the
lack of better options, uses the new-expression as the call site.
This patch fixes both problems.
Differential Revision: https://reviews.llvm.org/D41934
rdar://problem/12180598
llvm-svn: 322797
Add PostAllocatorCall program point to represent the moment in the analysis
between the operator new() call and the constructor call. Pointer cast from
"void *" to the correct object pointer type has already happened by this point.
The new program point, unlike the previously used PostImplicitCall, contains a
reference to the new-expression, which allows adding path diagnostics over it.
Differential Revision: https://reviews.llvm.org/D41800
rdar://problem/12180598
llvm-svn: 322796
Pointer escape event notifies checkers that a pointer can no longer be reliably
tracked by the analyzer. For example, if a pointer is passed into a function
that has no body available, or written into a global, MallocChecker would
no longer report memory leaks for such pointer.
In case of operator new() under -analyzer-config c++-allocator-inlining=true,
MallocChecker would start tracking the pointer allocated by operator new()
only to immediately meet a pointer escape event notifying the checker that the
pointer has escaped into a constructor (assuming that the body of the
constructor is not available) and immediately stop tracking it. Even though
it is theoretically possible for such constructor to put "this" into
a global container that would later be freed, we prefer to preserve the old
behavior of MallocChecker, i.e. a memory leak warning, in order to
be able to find any memory leaks in C++ at all. In fact, c++-allocator-inlining
*reduces* the amount of false positives coming from this-pointers escaping in
constructors, because it'd be able to inline constructors in some cases.
With other checkers working similarly, we simply suppress the escape event for
this-value of the constructor, regardless of analyzer options.
Differential Revision: https://reviews.llvm.org/D41797
rdar://problem/12180598
llvm-svn: 322795
Implements finding appropriate source locations for intermediate diagnostic
pieces in path-sensitive bug reports that need to descend into an inlined
operator new() call that was called via new-expression. The diagnostics have
worked correctly when operator new() was called "directly".
Differential Revision: https://reviews.llvm.org/D41409
rdar://problem/12180598
llvm-svn: 322791
Fix the const qualifier so that the operator defined in the tests indeed does
override the default global nothrow version of new.
Differential Revision: https://reviews.llvm.org/D41408
llvm-svn: 322790
The callback runs after operator new() and before the construction and allows
the checker to access the casted return value of operator new() (in the
sense of r322780) which is not available in the PostCall callback for the
allocator call.
Update MallocChecker to use the new callback instead of PostStmt<CXXNewExpr>,
which gets called after the constructor.
Differential Revision: https://reviews.llvm.org/D41406
rdar://problem/12180598
llvm-svn: 322787
Make sure that with c++-allocator-inlining=true we have the return value of
conservatively evaluated operator new() in the correct memory space (heap).
This is a regression/omission that worked well in c++-allocator-inlining=false.
Heap regions are superior to regular symbolic regions because they have
stricter aliasing constraints: heap regions do not alias each other or global
variables.
Differential Revision: https://reviews.llvm.org/D41266
rdar://problem/12180598
llvm-svn: 322780
According to [basic.stc.dynamic.allocation], the return type of any C++
overloaded operator new() is "void *". However, type of the new-expression
"new T()" and the type of "this" during construction of "T" are both "T *".
Hence an implicit cast, which is not present in the AST, needs to be performed
before the construction. This patch adds such cast in the case when the
allocator was indeed inlined. For now, in the case where the allocator was *not*
inlined we still use the same symbolic value (which is a pure SymbolicRegion of
type "T *") because it is consistent with how we represent the casts and causes
less surprise in the checkers after switching to the new behavior.
The better approach would be to represent that value as a cast over a
SymbolicRegion of type "void *", however we have technical difficulties
conjuring such region without any actual expression of type "void *" present in
the AST.
Differential Revision: https://reviews.llvm.org/D41250
rdar://problem/12180598
llvm-svn: 322777
The -analyzer-config c++-allocator-inlining experimental option allows the
analyzer to reason about C++ operator new() similarly to how it reasons about
regular functions. In this mode, operator new() is correctly called before the
construction of an object, with the help of a special CFG element.
However, the subsequent construction of the object was still not performed into
the region of memory returned by operator new(). The patch fixes it.
Passing the value from operator new() to the constructor and then to the
new-expression itself was tricky because operator new() has no call site of its
own in the AST. The new expression itself is not a good call site because it
has an incorrect type (operator new() returns 'void *', while the new expression
is a pointer to the allocated object type). Additionally, lifetime of the new
expression in the environment makes it unsuitable for passing the value.
For that reason, an additional program state trait is introduced to keep track
of the return value.
Finally this patch relaxes restrictions on the memory region class that are
required for inlining the constructor. This change affects the old mode as well
(c++-allocator-inlining=false) and seems safe because these restrictions were
an overkill compared to the actual problems observed.
Differential Revision: https://reviews.llvm.org/D40560
rdar://problem/12180598
llvm-svn: 322774
HTML diagnostics can be an overwhelming blob of pages of code.
This patch adds a checkbox which filters this list down to only the
lines *relevant* to the counterexample by e.g. skipping branches which
analyzer has assumed to be infeasible at a time.
The resulting amount of output is much smaller, and often fits on one
screen, and also provides a much more readable diagnostics.
Differential Revision: https://reviews.llvm.org/D41378
llvm-svn: 322612
In the security package, we have a simple syntactic check that warns about
strcpy() being insecure, due to potential buffer overflows.
Suppress that check's warning in the trivial situation when the source is an
immediate null-terminated string literal and the target is an immediate
sufficiently large buffer.
Patch by András Leitereg!
Differential Revision: https://reviews.llvm.org/D41384
llvm-svn: 322410
The current code used to not suppress the report, if the dereference was
performed in a macro, assuming it is that same macro.
However, the assumption might not be correct, and XNU has quite a bit of
code where dereference is actually performed in a different macro.
As the code uses macro name and not a unique identifier it might be fragile,
but in a worst-case scenario we would simply emit an extra diagnostic.
rdar://36160245
Differential Revision: https://reviews.llvm.org/D41749
llvm-svn: 322149
This addresses an issue introduced in r183451: since
`removePiecesWithInvalidLocations` is called *after* `adjustCallLocations`,
it is not necessary, and in fact harmful, to have this assertion in
adjustCallLocations.
Addresses rdar://36170689
Differential Revision: https://reviews.llvm.org/D41680
llvm-svn: 321682
Using ARC, strong, weak, and autoreleasing stack variables are implicitly
initialized with nil. This includes variable-length arrays of Objective-C object
pointers. However, in the analyzer we don't zero-initialize them. We used to,
but it accidentally regressed after r289618.
Under ARC, the array variable's initializer within DeclStmt is an
ImplicitValueInitExpr. Environment doesn't maintain any bindings for this
expression kind - instead it always knows that it's a known constant
(0 in our case), so it just returns the known value by calling
SValBuilder::makeZeroVal() (see EnvironmentManager::getSVal().
Commit r289618 had introduced reasonable behavior of SValBuilder::makeZeroVal()
for the arrays, which produces a zero-length compoundVal{}. When such value
is bound to arrays, in RegionStoreManager::bindArray() "remaining" items in the
array are default-initialized with zero, as in
RegionStoreManager::setImplicitDefaultValue(). The similar mechanism works when
an array is initialized by an initializer list that is too short, eg.
int a[3] = { 1, 2 };
would result in a[2] initialized with 0. However, in case of variable-length
arrays it didn't know if any more items need to be added,
because, well, the length is variable.
Add the default binding anyway, regardless of how many actually need
to be added. We don't really care how many, because the default binding covers
the whole array anyway.
Differential Revision: https://reviews.llvm.org/D41478
rdar://problem/35477763
llvm-svn: 321290
The bugreporter::trackNullOrUndefValue() mechanism contains a system of bug
reporter visitors that recursively call each other in order to track where a
null or undefined value came from, where each visitor represents a particular
tracking mechanism (track how the value was stored, track how the value was
returned from a function, track how the value was constrained to null, etc.).
Each visitor is only added once per value it needs to track. Almost. One
exception from this rule would be FindLastStoreBRVisitor that has two operation
modes: it contains a flag that indicates whether null stored values should be
suppressed. Two instances of FindLastStoreBRVisitor with different values of
this flag are considered to be different visitors, so they can be added twice
and produce the same diagnostic twice. This was indeed the case in the affected
test.
With the current logic of this whole machinery, such duplication seems
unavoidable. We should be able to safely add visitors with different flag
values without constructing duplicate diagnostic pieces. Hence the effort
in this commit to de-duplicate diagnostics regardless of what visitors
have produced them.
Differential Revision: https://reviews.llvm.org/D41258
llvm-svn: 321135
When trying to figure out where a null or undefined value came from,
parentheses and cast expressions are either completely irrelevant, or,
in the case of lvalue-to-rvale cast, straightforwardly lead us in the right
direction when we remove them.
There is a regression that causes a certain diagnostic to appear twice in the
path-notes.cpp test (changed to FIXME). It would be addressed in the next
commit.
Differential revision: https://reviews.llvm.org/D41254
llvm-svn: 321133
When reporting certain kinds of analyzer warnings, we use the
bugreporter::trackNullOrUndefValue mechanism, which is part of public checker
API, to understand where a zero, null-pointer, or garbage value came from,
which would highlight important events with respect to that value in the
diagnostic path notes, and help us suppress various false positives that result
from values appearing from particular sources.
Previously, we've lost track of the value when it was written into a memory
region that is not a plain variable. Now try to resume tracking in this
situation by finding where the last write to this region has occured.
Differential revision: https://reviews.llvm.org/D41253
llvm-svn: 321130
Since C++17, classes that have base classes can potentially be initialized as
aggregates. Trying to construct such objects through brace initialization was
causing the analyzer to crash when the base class has a non-trivial constructor,
while figuring target region for the base class constructor, because the parent
stack frame didn't contain the constructor of the subclass, because there is
no constructor for subclass, merely aggregate initialization.
This patch avoids the crash, but doesn't provide the actually correct region
for the constructor, which still remains to be fixed. Instead, construction
goes into a fake temporary region which would be immediately discarded. Similar
extremely conservative approach is used for other cases in which the logic for
finding the target region is not yet implemented, including aggregate
initialization with fields instead of base-regions (which is not C++17-specific
but also never worked, just didn't crash).
Differential revision: https://reviews.llvm.org/D40841
rdar://problem/35441058
llvm-svn: 321128
Artem Dergachev