aboutsummaryrefslogtreecommitdiff
path: root/test/Analysis/malloc-annotations.c
AgeCommit message (Collapse)Author
2013-04-06[analyzer] Shorten the malloc checker’s leak messageAnna Zaks
As per Ted’s suggestion! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178938 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-20[analyzer] Track malloc'd memory into struct fields.Jordan Rose
Due to improper modelling of copy constructors (specifically, their const reference arguments), we were producing spurious leak warnings for allocated memory stored in structs. In order to silence this, we decided to consider storing into a struct to be the same as escaping. However, the previous commit has fixed this issue and we can now properly distinguish leaked memory that happens to be in a struct from a buffer that escapes within a struct wrapper. Originally applied in r161511, reverted in r174468. <rdar://problem/12945937> git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177571 91177308-0d34-0410-b5e6-96231b3b80d8
2013-02-06[analyzer]Revert part of r161511; suppresses leak false positives in C++Anna Zaks
This is a "quick fix". The underlining issue is that when a const pointer to a struct is passed into a function, we do not invalidate the pointer fields. This results in false positives that are common in C++ (since copy constructors are prevalent). (Silences two llvm false positives.) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174468 91177308-0d34-0410-b5e6-96231b3b80d8
2012-11-15[analyzer] Report leaks at the closing brace of a function body.Jordan Rose
This fixes a few cases where we'd emit path notes like this: +---+ 1| v p = malloc(len); ^ |2 +---+ In general this should make path notes more consistent and more correct, especially in cases where the leak happens on the false branch of an if that jumps directly to the end of the function. There are a couple places where the leak is reported farther away from the cause; these are usually cases where there are several levels of nested braces before the end of the function. This still matches our current behavior for when there /is/ a statement after all the braces, though. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168070 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-24Fix analyzer tests.Ted Kremenek
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162588 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-16Allow multiple PathDiagnosticConsumers to be used with a BugReporter at the ↵Ted Kremenek
same time. This fixes several issues: - removes egregious hack where PlistDiagnosticConsumer would forward to HTMLDiagnosticConsumer, but diagnostics wouldn't be generated consistently in the same way if PlistDiagnosticConsumer was used by itself. - emitting diagnostics to the terminal (using clang's diagnostic machinery) is no longer a special case, just another PathDiagnosticConsumer. This also magically resolved some duplicate warnings, as we now use PathDiagnosticConsumer's diagnostic pruning, which has scope for the entire translation unit, not just the scope of a BugReporter (which is limited to a particular ExprEngine). As an interesting side-effect, diagnostics emitted to the terminal also have their trailing "." stripped, just like with diagnostics emitted to plists and HTML. This required some tests to be updated, but now the tests have higher fidelity with what users will see. There are some inefficiencies in this patch. We currently generate the report graph (from the ExplodedGraph) once per PathDiagnosticConsumer, which is a bit wasteful, but that could be pulled up higher in the logic stack. There is some intended duplication, however, as we now generate different PathDiagnostics (for the same issue) for different PathDiagnosticConsumers. This is necessary to produce the diagnostics that a particular consumer expects. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162028 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-08[analyzer] Track malloc'd regions stored in structs.Jordan Rose
The main blocker on this (besides the previous commit) was that ScanReachableSymbols was not looking through LazyCompoundVals. Once that was fixed, it's easy enough to clear out malloc data on return, just like we do when we bind to a global region. <rdar://problem/10872635> git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161511 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-22[analyzer] Malloc: Warn about use-after-free when memory ownership wasAnna Zaks
transfered with dataWithBytesNoCopy. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158958 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-20[analyzer] Malloc: cleanup, disallow free on relinquished memory.Anna Zaks
This commits sets the grounds for more aggressive use after free checking. We will use the Relinquished sate to denote that someone else is now responsible for releasing the memory. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158850 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-21[analyzer] Malloc: Utter the name of the leaked variable.Anna Zaks
Specifically, we use the last store of the leaked symbol in the leak diagnostic. (No support for struct fields since the malloc checker doesn't track those yet.) + Infrastructure to track the regions used in store evaluations. This approach is more precise than iterating the store to obtain the region bound to the symbol, which is used in RetainCount checker. The region corresponds to what is uttered in the code in the last store and we do not rely on the store implementation to support this functionality. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153212 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-01[analyzer] Fix a regression introduced in malloc withAnna Zaks
attributes, introduced in r151188. + the test to catch it. Thanks to Ahmed Charles for pointing this out. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151840 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-16[analyzer] Malloc Checker: Clean up bug naming:Anna Zaks
- Rename the category "Logic Error" -> "Memory Error". - Shorten all the messages. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150733 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-16[analyzer] Malloc Checker: Give up when a pointer escapes into a struct.Anna Zaks
We are not properly handling the memory regions that escape into struct fields, which led to a bunch of false positives. Be conservative here and give up when a pointer escapes into a struct. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150658 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-11[analyzer] Malloc Checker: Report a leak when we are returning freedAnna Zaks
memory. (As per one test case, the existing checker thought that this could cause a lot of false positives - not sure if that's valid, to be verified.) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150313 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-10[analyzer] MallocChecker Cleanup - harden against crashes, fix an errorAnna Zaks
(use of return instead of continue), wording. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150215 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-08[analyzer] Split the MallocChecker into two versions - pessimistic andAnna Zaks
optimistic. TODO: actually implement the pessimistic version of the checker. Ex: it needs to assume that any function that takes a pointer might free it. The optimistic version relies on annotations to tell us which functions can free the pointer. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150111 91177308-0d34-0410-b5e6-96231b3b80d8