aboutsummaryrefslogtreecommitdiff
path: root/test/Analysis/stackaddrleak.c
AgeCommit message (Collapse)Author
2013-05-01Re-apply "[analyzer] Model casts to bool differently from other numbers."Jordan Rose
This doesn't appear to be the cause of the slowdown. I'll have to try a manual bisect to see if there's really anything there, or if it's just the bot itself taking on additional load. Meanwhile, this change helps with correctness. This changes an assertion and adds a test case, then re-applies r180638, which was reverted in r180714. <rdar://problem/13296133> and PR15863 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180864 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-29Revert "[analyzer] Model casts to bool differently from other numbers."Jordan Rose
This seems to be causing quite a slowdown on our internal analyzer bot, and I'm not sure why. Needs further investigation. This reverts r180638 / 9e161ea981f22ae017b6af09d660bfc3ddf16a09. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180714 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-26[analyzer] Model casts to bool differently from other numbers.Jordan Rose
Casts to bool (and _Bool) are equivalent to checks against zero, not truncations to 1 bit or 8 bits. This improved reasoning does cause a change in the behavior of the alpha BoolAssignment checker. Previously, this checker complained about statements like "bool x = y" if 'y' was known not to be 0 or 1. Now it does not, since that conversion is well-defined. It's hard to say what the "best" behavior here is: this conversion is safe, but might be better written as an explicit comparison against zero. More usefully, besides improving our model of booleans, this fixes spurious warnings when returning the address of a local variable cast to bool. <rdar://problem/13296133> git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180638 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
2011-02-28[analyzer] Remove '-analyzer-check-objc-mem' flag, the nominee for best ↵Argyrios Kyrtzidis
misnomer award. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126676 91177308-0d34-0410-b5e6-96231b3b80d8
2011-02-28[analyzer] Migrate BuiltinFunctionChecker to CheckerV2.Argyrios Kyrtzidis
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126611 91177308-0d34-0410-b5e6-96231b3b80d8
2011-02-25Update test cases.Ted Kremenek
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126523 91177308-0d34-0410-b5e6-96231b3b80d8
2011-02-15[analyzer] Use the new registration mechanism on some of the internal ↵Argyrios Kyrtzidis
checks. These are: StackAddrLeakChecker ObjCAtSyncChecker UnixAPIChecker MacOSXAPIChecker The rest have/create implicit dependencies between checkers and need to be handled differently. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125559 91177308-0d34-0410-b5e6-96231b3b80d8
2010-06-17Tweak stack address checker to report multiple cases where globals may ↵Ted Kremenek
reference stack memory. Also refactor the diagnostics so that we print out the kind of stack memory returned. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@106210 91177308-0d34-0410-b5e6-96231b3b80d8
2010-06-17Rework StackAddrLeakChecker to find stores of stack memory addresses to ↵Ted Kremenek
global variables by inspecting the Store bindings instead of iterating over all the global variables in a translation unit. By looking at the store directly, we avoid cases where we cannot directly load from the global variable, such as an array (which can result in an assertion failure) and it also catches cases where we store stack addresses to non-scalar globals. Also, but not iterating over all the globals in the translation unit, we maintain cache locality, and the complexity of the checker becomes restricted to the complexity of the analyzed function, and doesn't scale with the size of the translation unit. This fixes PR 7383. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@106184 91177308-0d34-0410-b5e6-96231b3b80d8
2010-06-09Merge StackAddrLeakChecker and ReturnStackAddressChecker.Zhongxing Xu
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105687 91177308-0d34-0410-b5e6-96231b3b80d8
2010-06-09Directly compare the StackFrameContext. This greatly simplifies logic andZhongxing Xu
improves generality. Thanks Ted. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105686 91177308-0d34-0410-b5e6-96231b3b80d8
2010-06-08Add a checker check if a global variable holds a local variable's address afterZhongxing Xu
the function call is left where the local variable is declared. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105602 91177308-0d34-0410-b5e6-96231b3b80d8