This involved refactoring some common pointer-escapes code onto CallEvent,
then having MallocChecker use those callbacks for whether or not to consider
a pointer's /ownership/ as escaping. This still needs to be pinned down, and
probably we want to make the new argumentsMayEscape() function a little more
discerning (content invalidation vs. ownership/metadata invalidation), but
this is a good improvement.

As a bonus, also remove CallOrObjCMessage from the source completely.

llvm-svn: 159557

This is intended to replace CallOrObjCMessage, and is eventually intended to be
used for anything that cares more about /what/ is being called than /how/ it's
being called. For example, inlining destructors should be the same as inlining
blocks, and checking __attribute__((nonnull)) should apply to the allocator
calls generated by operator new.

llvm-svn: 159554

The implicit global allocation functions do not have valid source locations,
but we still want to treat them as being "system header" functions for the
purposes of how they affect program state.

llvm-svn: 159160

relinquish memory.

llvm-svn: 159043

llvm-svn: 159037

transfered with dataWithBytesNoCopy.

llvm-svn: 158958

llvm-svn: 158875

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.

llvm-svn: 158850

(Fixes radar://11691035 PR13140)

llvm-svn: 158703

Specifically, although the bitmap context does not take ownership of the
buffer (unlike CGBitmapContextCreateWithData), the data buffer can be extracted
out of the created CGContextRef. Thus the buffer is not leaked even if its
original pointer goes out of scope, as long as
- the context escapes, or
- it is retrieved via CGBitmapContextGetData and freed.

Actually implementing that logic is beyond the current scope of MallocChecker,
so for now CGBitmapContextCreate goes on our system function exception list.

llvm-svn: 158579

Add a concept of symbolic memory region belonging to heap memory space.
When comparing symbolic regions allocated on the heap, assume that they
do not alias. 

Use symbolic heap region to suppress a common false positive pattern in
the malloc checker, in code that relies on malloc not returning the
memory aliased to other malloc allocations, stack.

llvm-svn: 158136

llvm-svn: 157886

llvm-svn: 157081

allocating functions.

llvm-svn: 157037

We report a leak at a point a leaked variable is no longer accessible.
The statement that happens to be at that point is not relevant to the
leak diagnostic and, thus, should not be highlighted.

radar://11178519

llvm-svn: 156530

(Since we don't have a generic pointer escape callback, modify
ExprEngineCallAndReturn as well as the malloc checker.)

llvm-svn: 156134

llvm-svn: 155963

(Applied changes to CStringAPI, Malloc, and Taint.)

This might almost never happen, but we should not crash even if it does.
This fixes a crash on the internal analyzer buildbot, where postgresql's
configure was redefining memmove (radar://11219852).

llvm-svn: 154451

Fixes a false positive (radar://11152419). The current solution of
adding the info into 3 places is quite ugly. Pending a generic pointer
escapes callback.

llvm-svn: 153731

llvm-svn: 153453

[analyzer] Tighten up the realloc() failure path note generation...make sure we get the right realloc()!

llvm-svn: 153370

[analyzer] Restart path diagnostic generation if any of the visitors change the report configuration while walking the path.

This required adding a change count token to BugReport, but also allowed us to ditch ImmutableList as the BugReporterVisitor data type.

Also, remove the hack from MallocChecker, now that visitors appear in the opposite order. This is not exactly a fix, but the common case -- custom diagnostics after generic ones -- is now the default behavior.

llvm-svn: 153369

[analyzer] Add a clone() method to BugReporterVisitor, so that we'll be able to reset diagnostic generation.

llvm-svn: 153368

llvm-svn: 153232

llvm-svn: 153220

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.

llvm-svn: 153212

[analyzer] Mark a failed-realloc's result as an interesting symbol between the realloc call and the null check, so we get nicer path notes. Fixes a regression introduced by the diagnostic pruning added in r152361.

This is accomplished by calling markInteresting /during/ path diagnostic generation, and as such relies on deterministic ordering of BugReporterVisitors -- namely, that BugReporterVisitors are run in /reverse/ order from how they are added. (Right now that's a consequence of storing visitors in an ImmutableList, where new items are added to the front.) It's a little hacky, but it works for now.

I think this is the best we can do without storing the relation between the old and new symbols, and that would be a hit whether or not there ends up being an error.

llvm-svn: 153010

Do not display the standard "Returning from 'foo'", when a stack hint is
available.

llvm-svn: 152964

The symbol-aware stack hint combines the checker-provided message
with the information about how the symbol was passed to the callee: as
a parameter or a return value.

For malloc, the generated messages look like this :
"Returning from 'foo'; released memory via 1st parameter"
"Returning from 'foo'; allocated memory via 1st parameter"
"Returning from 'foo'; allocated memory returned"
"Returning from 'foo'; reallocation of 1st parameter failed"


(We are yet to handle cases when the symbol is a field in a struct or
an array element.)

llvm-svn: 152962

BugVisitor DiagnosticPieces.

When checkers create a DiagnosticPieceEvent, they can supply an extra
string, which will be concatenated with the call exit message for every
call on the stack between the diagnostic event and the final bug report.
(This is a simple version, which could be/will be further enhanced.)

For example, this is used in Malloc checker to produce the ",
which allocated memory" in the following example:

static char *malloc_wrapper() { // 2. Entered call from 'use'
    return malloc(12);    // 3. Memory is allocated
}

void use() {
    char *v;
    v = malloc_wrapper(); // 1. Calling 'malloc_wrappers'
        // 4. Returning from 'malloc_wrapper', which allocated memory
}                         // 5. Memory is never released; potential
memory leak

llvm-svn: 152837

Essentially, a bug centers around a story for various symbols and regions.  We should only include
the path diagnostic events that relate to those symbols and regions.

The pruning is done by associating a set of interesting symbols and regions with a BugReporter, which
can be modified at BugReport creation or by BugReporterVisitors.

This patch reduces the diagnostics emitted in several of our test cases.  I've vetted these as
having desired behavior.  The only regression is a missing null check diagnostic for the return
value of realloc() in test/Analysis/malloc-plist.c.  This will require some investigation to fix,
and I have added a FIXME to the test case.

llvm-svn: 152361

llvm-svn: 152080

llvm-svn: 152078

calling an ObjC method ending with 'NoCopy'.

llvm-svn: 152037

attributes, introduced in r151188.

+ the test to catch it.

Thanks to Ahmed Charles for pointing this out.

llvm-svn: 151840

funopen, setvbuf.

Teach the checker and the engine about these APIs to resolve malloc
false positives. As I am adding more of these APIs, it is clear that all
this should be factored out into a separate callback (for example,
region escapes). Malloc, KeyChainAPI and RetainRelease checkers could
all use it.

llvm-svn: 151737

When allocated buffer is passed to CF/NS..NoCopy functions, the
ownership is transfered unless the deallocator argument is set to
'kCFAllocatorNull'.

llvm-svn: 151608

closest function context. 

This prevents us from uniqueing all leaks from the same allocation
helper. radar://10932226

llvm-svn: 151592

Assume none of the ObjC messages defined in system headers free memory,
except for the ones containing 'freeWhenDone' selector. Currently, just
assume that the region escapes to the messages with 'freeWhenDone'
(ideally, we want to treat it as 'free()').

For now, always assume that regions escape when passed to C++ methods.

llvm-svn: 151410

When we find two leak reports with the same allocation site, report only
one of them.

Provide a helper method to BugReporter to facilitate this.

llvm-svn: 151287