| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
Move a repeated block of code into a function.
Differential Revision: https://reviews.llvm.org/D39584
llvm-svn: 317849
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the issue breaking the postgresql bot, purely by chance exposed
through taint checker, somehow appearing after
https://reviews.llvm.org/D38358 got committed.
The backstory is that the taint checker requests SVal for the value of
the pointer, and analyzer has a "fast path" in the getter to return a
constant when we know that the value is constant.
Unfortunately, the getter requires a cast to get signedness correctly,
and for the pointer `void *` the cast crashes.
This is more of a band-aid patch, as I am not sure what could be done
here "correctly", but it should be applied in any case to avoid the
crash.
Differential Revision: https://reviews.llvm.org/D39862
llvm-svn: 317839
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patches the solver to assume that bitwise OR of an unsigned value with a
constant always produces a value larger-or-equal than the constant, and
bitwise AND with a constant always produces a value less-or-equal than
the constant.
This patch is especially useful in the context of using bitwise
arithmetic for error code encoding: the analyzer would be able to state
that the error code produced using a bitwise OR is non-zero.
Differential Revision: https://reviews.llvm.org/D39707
llvm-svn: 317820
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do not crash when trying to compute x && y or x || y where x and y are
of a vector type.
For now we do not seem to properly model operations with vectors. In particular,
operations && and || on a pair of vectors are not short-circuit, unlike regular
logical operators, so even our CFG is incorrect.
Avoid the crash, add respective FIXME tests for later.
Differential Revision: https://reviews.llvm.org/D39682
rdar://problem/34317663
llvm-svn: 317700
|
|
|
|
|
|
|
|
|
|
|
| |
Do not crash when trying to define and call a non-standard
strcpy(unsigned char *, unsigned char *) during analysis.
At the same time, do not try to actually evaluate the call.
Differential Revision: https://reviews.llvm.org/D39422
llvm-svn: 317565
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D39577
llvm-svn: 317294
|
|
|
|
|
|
|
|
| |
BugReporterVisitor
Differential Revision: https://reviews.llvm.org/D37935
llvm-svn: 316963
|
|
|
|
|
|
|
|
|
|
| |
The analyzer did not return an UndefVal in case a negative value was left
shifted. I also altered the UndefResultChecker to emit a clear warning in this
case.
Differential Revision: https://reviews.llvm.org/D39423
llvm-svn: 316924
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now when a template is instantiated more times and there is a bug found in the
instantiations the issue hash will be different for each instantiation even if
every other property of the bug (path, message, location) is the same.
This patch aims to resolve this issue. Note that explicit specializations still
generate different hashes but that is intended.
Differential Revision: https://reviews.llvm.org/D38728
llvm-svn: 316900
|
|
|
|
|
|
|
|
|
|
| |
Extend ExprInspection checker to make it possible to dump the issue hash of
arbitrary expressions. This change makes it possible to make issue hash related
tests more concise and also makes debugging issue hash related problems easier.
Differential Revision: https://reviews.llvm.org/D38844
llvm-svn: 316899
|
|
|
|
|
|
|
|
|
|
| |
checker
A patch by zdtorok (Zoltán Dániel Török)!
Differential Revision: https://reviews.llvm.org/D33729
llvm-svn: 316892
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D37470
llvm-svn: 316885
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added new enum in order to differentiate the warning messages on "misusing" into
3 categories: function calls, moving an object, copying an object. (At the
moment the checker gives the same message in case of copying and moving.)
Additional test cases added as well.
Differential Revision: https://reviews.llvm.org/D38674
llvm-svn: 316852
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
handling method calls on base-class sub-objects
An earlier solution from Artem r315301 solves the reset problem, however, the
reports should be handled the same way in case of method calls. We should not
just report the base class of the object where the method was defined but the
whole object.
Fixed false positive which came from not removing the subobjects in case of a
state-resetting function. (Just replaced the State->remove(...) call to
removeFromState(..) which was defined exactly for that purpose.)
Some minor typos fixed in this patch as well which did not worth a whole new
patch in my opinion, so included them here.
Differential Revision: https://reviews.llvm.org/D31538
llvm-svn: 316850
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The loop unrolling feature aims to track the maximum possible steps a loop can
make. In order to implement this, it investigates the initial value of the
counter variable and the bound number. (It has to be known.)
These numbers are used as llvm::APInts, however, it was not checked if their
bitwidths are the same which lead to some crashes.
This revision solves this problem by extending the "shorter" one (to the length
of the "longer" one).
For the detailed bug report, see: https://bugs.llvm.org/show_bug.cgi?id=34943
Differential Revision: https://reviews.llvm.org/D38922
llvm-svn: 316830
|
|
|
|
|
|
|
|
| |
BodyFarm.cpp
Differential Revision: https://reviews.llvm.org/D39208
llvm-svn: 316400
|
|
|
|
|
|
|
|
|
|
|
| |
In getLValueElement Base may represent the address of a label
(as in the newly-added test case), in this case it's not a loc::MemRegionVal
and Base.castAs<loc::MemRegionVal>() triggers an assert, this diff makes
getLValueElement return UnknownVal instead.
Differential revision: https://reviews.llvm.org/D39174
llvm-svn: 316399
|
|
|
|
|
|
|
|
| |
Patch by: Adam Balogh!
Differential Revision: https://reviews.llvm.org/D39048
llvm-svn: 316157
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases the analyzer didn't expect an array-type variable to be
initialized with anything other than a string literal. The patch essentially
removes the assertion, and ensures relatively sane behavior.
There is a bigger problem with these initializers. Currently our memory model
(RegionStore) is being ordered to initialize the array with a region that
is assumed to be storing the initializer rvalue, and it guesses to copy
the contents of that region to the array variable. However, it would make
more sense for RegionStore to receive the correct initializer in the first
place. This problem isn't addressed with this patch.
rdar://problem/27248428
Differential Revision: https://reviews.llvm.org/D23963
llvm-svn: 315750
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The checker used to crash when a mempcpy's length argument is symbolic. In this
case the cast from 'void *' to 'char *' failed because the respective
ElementRegion that represents cast is hard to add on top of the existing
ElementRegion that represents the offset to the last copied byte, while
preseving a sane memory region structure.
Additionally, a few test cases are added (to casts.c) which demonstrate problems
caused by existing sloppy work we do with multi-layer ElementRegions. If said
cast would be modeled properly in the future, these tests would need to be
taken into account.
Differential Revision: https://reviews.llvm.org/D38797
llvm-svn: 315742
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is not uncommon for the users to make their own wrappers around
CoreFoundation's CFRetain and CFRelease functions that are defensive
against null references. In such cases CFRetain is often incorrectly
marked as CF_RETURNS_RETAINED. Ignore said annotation and treat such
wrappers similarly to the regular CFRetain.
rdar://problem/31699502
Differential Revision: https://reviews.llvm.org/D38877
llvm-svn: 315736
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D38867
llvm-svn: 315655
|
|
|
|
|
|
| |
clang/StaticAnalyzer/Core/PathSensitive/SVals.h, s/IncludeBaseRegion/IncludeBaseRegions/g [-Wdocumentation]
llvm-svn: 315572
|
|
|
|
| |
llvm-svn: 315492
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D38764
llvm-svn: 315488
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D30295
llvm-svn: 315462
|
|
|
|
|
|
|
|
|
|
|
| |
If a method is resetting the state of an object that was moved from, it should
be safe to use this object again. However if the method was defined in a parent
class, but used in a child class, the reset didn't happen from the checker's
perspective.
Differential Revision: https://reviews.llvm.org/D31538
llvm-svn: 315301
|
|
|
|
|
|
|
|
|
| |
This method injects additional information into program state dumps,
describing which objects have been moved from.
Differential Revision: https://reviews.llvm.org/D31541
llvm-svn: 315300
|
|
|
|
|
|
|
|
|
| |
This method injects additional information into program state dumps,
describing states of mutexes tracked by the checker.
Differential Revision: https://reviews.llvm.org/D37805
llvm-svn: 315298
|
|
|
|
|
|
|
|
| |
Patch by: Rafael Stahl!
Differential Revision: https://reviews.llvm.org/D37478
llvm-svn: 315296
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The analyzer now realizes that C++ std::initializer_list objects and
Objective-C boxed structure/array/dictionary expressions can potentially
maintain a reference to the objects that were put into them. This avoids
false memory leak posivites and a few other issues.
This is a conservative behavior; for now, we do not model what actually happens
to the objects after being passed into such initializer lists.
rdar://problem/32918288
Differential Revision: https://reviews.llvm.org/D35216
llvm-svn: 314975
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In ProgramState::getSVal(Location, Type) API which dereferences a pointer value,
when the optional Type parameter is not supplied and the Location is not typed,
type should have been guessed on a best-effort basis by inspecting the Location
more deeply. However, this never worked; the auto-detected type was instead
a pointer type to the correct type.
Fixed the issue and added various test cases to demonstrate which parts of the
analyzer were affected (uninitialized pointer argument checker, C++ trivial copy
modeling, Google test API modeling checker).
Additionally, autodetected void types are automatically replaced with char,
in order to simplify checker APIs. Which means that if the location is a void
pointer, getSVal() would read the first byte through this pointer
and return its symbolic value.
Fixes pr34305.
Differential Revision: https://reviews.llvm.org/D38358
llvm-svn: 314910
|
|
|
|
|
|
|
|
|
| |
Fixes the test failure: temporary is now bound to std::string, tests
fully pass on Linux.
This reverts commit b36ee0924038e1d95ea74230c62d46e05f80587e.
llvm-svn: 314859
|
|
|
|
|
|
|
|
| |
The test retain-release.m fails with this patch.
Differential Revision: https://reviews.llvm.org/D38487
llvm-svn: 314831
|
|
|
|
|
|
|
|
|
| |
Only assume that IOBSDNameMatching and friends increment a reference counter
if their return type is a CFMutableDictionaryRef.
Differential Revision: https://reviews.llvm.org/D38487
llvm-svn: 314820
|
|
|
|
|
|
|
|
|
|
| |
This function can now track null pointer through simple pointer arithmetic,
such as '*&*(p + 2)' => 'p' and so on, displaying intermediate diagnostic pieces
for the user to understand where the null pointer is coming from.
Differential Revision: https://reviews.llvm.org/D37025
llvm-svn: 314290
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This API is used by checkers (and other entities) in order to track where does
a value originate from, by jumping from an expression value of which is equal
to that value to the expression from which this value has "appeared". For
example, it may be an lvalue from which the rvalue was loaded, or a function
call from which the dereferenced pointer was returned.
The function now avoids incorrectly unwrapping implicit lvalue-to-rvalue casts,
which caused crashes and incorrect intermediate diagnostic pieces. It also no
longer relies on how the expression is written when guessing what it means.
Fixes pr34373 and pr34731.
rdar://problem/33594502
Differential Revision: https://reviews.llvm.org/D37023
llvm-svn: 314287
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes analyzer's crash on the newly added test case
(see also https://bugs.llvm.org/show_bug.cgi?id=34374).
Pointers subtraction appears to be modeled incorrectly
in the following example:
char* p;
auto n = p - reinterpret_cast<char*>((unsigned long)1);
In this case the analyzer (built without this patch)
tries to create a symbolic value for the difference
treating reinterpret_cast<char*>((unsigned long)1)
as an integer, that is not correct.
Differential revision: https://reviews.llvm.org/D38214
Test plan: make check-all
llvm-svn: 314141
|
|
|
|
|
|
|
|
| |
Patch by: Reka Nikolett Kovacs
Differential Revision: https://reviews.llvm.org/D35796
llvm-svn: 313973
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D37910
llvm-svn: 313944
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D37978
llvm-svn: 313866
|
|
|
|
|
|
| |
https://reviews.llvm.org/D37908
llvm-svn: 313385
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Clang part of https://reviews.llvm.org/D37563
Reviewers: bkramer
Subscribers: vsk, cfe-commits
Differential Revision: https://reviews.llvm.org/D37564
llvm-svn: 313156
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The implementation is in AnalysisDeclContext.cpp and the class is called
AnalysisDeclContext.
Making those match up has numerous benefits, including:
- Easier jump from header to/from implementation.
- Easily identify filename from class.
Differential Revision: https://reviews.llvm.org/D37500
llvm-svn: 312671
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D37499
llvm-svn: 312670
|
|
|
|
|
|
| |
The for loop already checks that Idx < NumOfArgs.
llvm-svn: 312525
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
So far we used a value of 10 which was useful for testing but produces many false-positives in real programs. The usual suspicious clones we find seem to be at around a complexity value of 70 and for normal clone-reporting everything above 50 seems to be a valid normal clone for users, so let's just go with 50 for now and set this as the new default value.
This patch also explicitly sets the complexity value for the regression tests as they serve more of a regression testing/debugging purpose and shouldn't really be reported by default in real programs. I'll add more tests that reflect actual found bugs that then need to pass with the default setting in the future.
Reviewers: NoQ
Subscribers: cfe-commits, javed.absar, xazax.hun, v.g.vassilev
Differential Revision: https://reviews.llvm.org/D34178
llvm-svn: 312468
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch aims at optimizing the CloneChecker for larger programs. Before this
patch we took around 102 seconds to analyze sqlite3 with a complexity value of
50. After this patch we now take 2.1 seconds to analyze sqlite3.
The biggest performance optimization is that we now put the constraint for group
size before the constraint for the complexity. The group size constraint is much
faster in comparison to the complexity constraint as it only does a simple
integer comparison. The complexity constraint on the other hand actually
traverses each Stmt and even checks the macro stack, so it is obviously not able
to handle larger amounts of incoming clones. The new order filters out all the
single-clone groups that the type II constraint generates in a faster way before
passing the fewer remaining clones to the complexity constraint. This reduced
runtime by around 95%.
The other change is that we also delay the verification part of the type II
clones back in the chain of constraints. This required to split up the
constraint into two parts - a verification and a hash constraint (which is also
making it more similar to the original design of the clone detection algorithm).
The reasoning for this is the same as before: The verification constraint has to
traverse many statements and shouldn't be at the start of the constraint chain.
However, as the type II hashing has to be the first step in our algorithm, we
have no other choice but split this constrain into two different ones. Now our
group size and complexity constrains filter out a chunk of the clones before
they reach the slow verification step, which reduces the runtime by around 8%.
I also kept the full type II constraint around - that now just calls it's two
sub-constraints - in case someone doesn't care about the performance benefits
of doing this.
Reviewers: NoQ
Reviewed By: NoQ
Subscribers: klimek, v.g.vassilev, xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D34182
llvm-svn: 312222
|
|
|
|
| |
llvm-svn: 311936
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This diff fixes modeling of arithmetic
expressions where pointers are treated as integers
(i.e. via C-style / reinterpret casts).
For now we return UnknownVal unless the operation is a comparison.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D37120
llvm-svn: 311935
|