| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Based on feedback from Jordan.
llvm-svn: 183600
|
|
|
|
|
|
|
|
|
| |
init..]” is called.
Jordan has pointed out that it is valuable to warn in cases when the arguments to init escape.
For example, NSData initWithBytes id not going to free the memory.
llvm-svn: 183062
|
|
|
|
|
|
| |
to be in JSONKit
llvm-svn: 183055
|
|
|
|
| |
llvm-svn: 182702
|
|
|
|
| |
llvm-svn: 182642
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This class is a StmtVisitor that distinguishes between block-level and
non-block-level statements in a CFG. However, it does so using a hard-coded
idea of which statements might be block-level, which probably isn't accurate
anymore. The only implementer of the CFGStmtVisitor hierarchy was the
analyzer's DeadStoresChecker, and the analyzer creates a linearized CFG
anyway (every non-trivial statement is a block-level statement).
This also allows us to remove the block-expr map ("BlkExprMap"), which
mapped statements to positions in the CFG. Apart from having a helper type
that really should have just been Optional<unsigned>, it was only being
used to ask /if/ a particular expression was block-level, for traversal
purposes in CFGStmtVisitor.
llvm-svn: 181945
|
|
|
|
|
|
| |
(Modifying the checker to record that the values are no longer nil will be done separately.)
llvm-svn: 181744
|
|
|
|
| |
llvm-svn: 181738
|
|
|
|
| |
llvm-svn: 181616
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider this example:
char *p = malloc(sizeof(char));
systemFunction(&p);
free(p);
In this case, when we call systemFunction, we know (because it's a system
function) that it won't free 'p'. However, we /don't/ know whether or not
it will /change/ 'p', so the analyzer is forced to invalidate 'p', wiping
out any bindings it contains. But now the malloc'd region looks like a
leak, since there are no more bindings pointing to it, and we'll get a
spurious leak warning.
The fix for this is to notice when something is becoming inaccessible due
to invalidation (i.e. an imperfect model, as opposed to being explicitly
overwritten) and stop tracking it at that point. Currently, the best way
to determine this for a call is the "indirect escape" pointer-escape kind.
In practice, all the patch does is take the "system functions don't free
memory" special case and limit it to direct parameters, i.e. just the
arguments to a call and not other regions accessible to them. This is a
conservative change that should only cause us to escape regions more
eagerly, which means fewer leak warnings.
This isn't perfect for several reasons, the main one being that this
example is treated the same as the one above:
char **p = malloc(sizeof(char *));
systemFunction(p + 1);
// leak
Currently, "addresses accessible by offsets of the starting region" and
"addresses accessible through bindings of the starting region" are both
considered "indirect" regions, hence this uniform treatment.
Another issue is our longstanding problem of not distinguishing const and
non-const bindings; if in the first example systemFunction's parameter were
a char * const *, we should know that the function will not overwrite 'p',
and thus we can safely report the leak.
<rdar://problem/13758386>
llvm-svn: 181607
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is unfortunate that we have to mark these exceptions in multiple places.
This was already in CallEvent. I suppose it does let us be more precise
about saying /which/ arguments have their retain counts invalidated -- the
connection's is still valid even though the context object's isn't -- but
we're not tracking the retain count of XPC objects anyway.
<rdar://problem/13783514>
llvm-svn: 180904
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In an Objective-C for-in loop "for (id element in collection) {}", the loop
will run 0 times if the collection is nil. This is because the for-in loop
is implemented using a protocol method that returns 0 when there are no
elements to iterate, and messages to nil will result in a 0 return value.
At some point we may want to actually model this message send, but for now
we may as well get the nil case correct, and avoid the false positives that
would come with this case.
<rdar://problem/13744632>
llvm-svn: 180639
|
|
|
|
| |
llvm-svn: 180579
|
|
|
|
|
|
|
|
|
|
|
| |
CallEnter::getCallExpr to return non-NULL
We get a CallEnter with a null expression, when processing a destructor. All other users of
CallEnter::getCallExpr work fine with null as return value.
(Addresses PR15832, Thanks to Jordan for reducing the test case!)
llvm-svn: 180234
|
|
|
|
|
|
|
|
|
|
|
|
| |
invalidators exist
- If only partial invalidators exist and there are no full invalidators in @implementation, report every ivar that has
not been invalidated. (Previously, we reported the first Ivar in the list, which could actually have been invalidated
by a partial invalidator. The code assumed you cannot have only partial invalidators.)
- Do not report missing invalidation method declaration if a partial invalidation method declaration exists.
llvm-svn: 180170
|
|
|
|
|
|
|
|
|
|
| |
count checker leaks.
The uniqueing location is the location which is part of the hash used to determine if two reports are
the same. This is used by the CmpRuns.py script to compare two analyzer runs and determine which
warnings are new.
llvm-svn: 180166
|
|
|
|
|
|
|
|
| |
No functionality change.
<rdar://problem/13710586>
llvm-svn: 180075
|
|
|
|
|
|
|
| |
This handles the false positive leak warning in PR15374, and also serves
as a basic model for the strsep() function.
llvm-svn: 180069
|
|
|
|
|
|
|
| |
This improves our handling of dynamic_cast and devirtualization for
objects allocated by 'new'.
llvm-svn: 180051
|
|
|
|
|
|
|
|
|
|
|
| |
This was slightly tricky because BlockDecls don't currently store an
inferred return type. However, we can rely on the fact that blocks with
inferred return types will have return statements that match the inferred
type.
<rdar://problem/13665798>
llvm-svn: 179699
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an opt-in tweak for leak diagnostics to reference the allocation
site if the diagnostic consumer only wants a pithy amount of information,
and not the entire path.
This is a strawman enhancement that I expect to see some experimentation
with over the next week, and can go away if we don't want it.
Currently it is only used by RetainCountChecker, but could be used
by MallocChecker if and when we decide this should stay in.
llvm-svn: 179634
|
|
|
|
| |
llvm-svn: 179627
|
|
|
|
| |
llvm-svn: 179580
|
|
|
|
| |
llvm-svn: 179428
|
|
|
|
| |
llvm-svn: 179410
|
|
|
|
| |
llvm-svn: 179395
|
|
|
|
|
|
| |
By Adam Schnitzer!
llvm-svn: 179352
|
|
|
|
|
|
| |
isTrackedByCurrentChecker
llvm-svn: 179242
|
|
|
|
| |
llvm-svn: 179235
|
|
|
|
| |
llvm-svn: 179234
|
|
|
|
|
|
| |
Now the check is also applied to arguments for Objective-C method calls and to 'this' pointer.
llvm-svn: 179230
|
|
|
|
|
|
| |
Fixes PR13476
llvm-svn: 179228
|
|
|
|
|
|
|
|
|
| |
from init, step into init.
The heuristic here (proposed by Jordan) is that, usually, if a leak is due to an early exit from init, the allocation site will be
a call to alloc. Note that in other cases init resets self to [super init], which becomes the allocation site of the object.
llvm-svn: 179221
|
|
|
|
|
|
| |
other functions.
llvm-svn: 179219
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the analyzer used isIntegerType() everywhere, which uses the C
definition of "integer". The C++ predicate with the same behavior is
isIntegerOrUnscopedEnumerationType().
However, the analyzer is /really/ using this to ask if it's some sort of
"integrally representable" type, i.e. it should include C++11 scoped
enumerations as well. hasIntegerRepresentation() sounds like the right
predicate, but that includes vectors, which the analyzer represents by its
elements.
This commit audits all uses of isIntegerType() and replaces them with the
general isIntegerOrEnumerationType(), except in some specific cases where
it makes sense to exclude scoped enumerations, or any enumerations. These
cases now use isIntegerOrUnscopedEnumerationType() and getAs<BuiltinType>()
plus BuiltinType::isInteger().
isIntegerType() is hereby banned in the analyzer - lib/StaticAnalysis and
include/clang/StaticAnalysis. :-)
Fixes real assertion failures. PR15703 / <rdar://problem/12350701>
llvm-svn: 179081
|
|
|
|
|
|
|
|
|
|
|
| |
report mismatched deallocator
Test that the path notes do not change. I don’t think we should print a note on escape.
Also, I’ve removed a check that assumed that the family stored in the RefStete could be
AF_None and added an assert in the constructor.
llvm-svn: 179075
|
|
|
|
| |
llvm-svn: 179034
|
|
|
|
|
|
| |
As per Ted’s suggestion!
llvm-svn: 178938
|
|
|
|
| |
llvm-svn: 178935
|
|
|
|
|
|
| |
Now treat AF_None family as impossible in isTrackedFamily()
llvm-svn: 178899
|
|
|
|
|
|
|
|
| |
As mentioned in the previous commit message, the use-after-free and
double-free warnings for 'delete' are worth enabling even while the
leak warnings still have false positives.
llvm-svn: 178891
|
|
|
|
|
|
|
|
|
|
|
|
| |
This splits the leak-checking part of alpha.cplusplus.NewDelete into a
separate user-level checker, alpha.cplusplus.NewDeleteLeaks. All the
difficult false positives we've seen with the new/delete checker have been
spurious leak warnings; the use-after-free warnings and mismatched
deallocator warnings, while rare, have always been valid.
<rdar://problem/6194569>
llvm-svn: 178890
|
|
|
|
| |
llvm-svn: 178862
|
|
|
|
|
|
|
|
|
| |
The statement passed to isTrackedFamily() might be a user defined function calling malloc; in this case we got AF_NONE family for this function.
Now the allocation family is derived from Sym, that holds a family of a real allocator.
This commit is also a movement towards getting rid of tracking memory allocating by unknown means.
llvm-svn: 178834
|
|
|
|
| |
llvm-svn: 178831
|
|
|
|
| |
llvm-svn: 178820
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MallocChecker.cpp
This fixes an issue pointed to by Jordan: if unix.Malloc and unix.MismatchedDeallocator are both on, then we end up still tracking leaks of memory allocated by new.
Moved the guards right before emitting the bug reports to unify and simplify the logic of handling of multiple checkers. Now all the checkers perform their checks regardless of if they were enabled, or not, and it is decided just before the emitting of the report, if it should be emitted. (idea from Anna).
Additional changes:
improved test coverage for checker correlations;
refactoring: BadDealloc -> MismatchedDealloc
llvm-svn: 178814
|
|
|
|
|
|
|
|
|
| |
...and add a new test case.
I thought this was broken, but it isn't; refactoring and reformatting anyway
so that I don't make the same mistake again. No functionality change.
llvm-svn: 178799
|
|
|
|
|
|
|
|
| |
(Apple)”
As they are relevant on both Mac and iOS.
llvm-svn: 178687
|
|
|
|
|
|
| |
This also allows us to ensure IDC/return null suppression gets triggered in such cases.
llvm-svn: 178686
|