http://llvm.org/bugs/show_bug.cgi?id=2505
Summary: Support for autorelease pools and 'autorelease' messages
in memory leak analysis
Product: clang
Version: unspecified
Platform: Macintosh
OS/Version: MacOS X
Status: NEW
Keywords: new-feature
Severity: enhancement
Priority: P2
Component: Semantic Analyzer
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [email protected]
In a non-GC enrivonment, clang static analyzer stops tracking reference counts
as soon as it sees an "autorelease" message sent to an object (tracking is
stopped in CFRefCount.cpp:879).
This causes clang to miss possible memory leaks and uses after release. Some
concrete examples:
- (void)useAfterRelease
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSString *str = [[NSString alloc] initWithString:@"some string data"]; //
rc(str)=1
[str autorelease]; // rc(str)=1, added to local autorelease pool 'pool'
[pool release]; // rc(str)=0, since local autorelease pool 'pool' is released
NSLog(@"%@", str); // 'str' is used after release. Not reported by clang
checker.
}
- (void)memoryLeak
{
NSString *str = [[NSString alloc] initWithString:@"some string data"]; //
rc(str)=1
[str retain]; // rc(str)=2
[str autorelease]; // rc(str)=2, and will be 1 after the current event.
// 'str' is leaked, since it goes out of scope. Not reported by clang
checker.
}
Clang should probably track local autorelease pools (which may be nested) and
handle 'autorelease' messages just as it handles 'release' messages, but taking
into account the knowledge about autorelease pools.
Clang revision used: 52881
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
