haoNoQ
commented
5 years ago The non-stale links to the discussion: http://lists.llvm.org/pipermail/cfe-dev/2008-June/001980.html http://lists.llvm.org/pipermail/cfe-dev/2008-June/002057.html
The false positive have been suppressed as part of llvm/llvm-bugzilla-archive#3714 : NSWindow objects are not tracked at all, so we report neither leaks nor overreleases. Nothing changed since then.
I guess i'll leave this bug report around in order to track the respective class of false negatives, but this would probably still be in our backlog of bugs for a while.
The FN is also tracked internally as rdar://problem/6062711.
tkremenek
Extended Description
This bug report tracks the progress of the issue originally mentioned in the following cfe-dev threads:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-June/001980.html http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-June/002057.html
The retain/release checker currently has a heuristic for NSWindow objects that they are considered "self-owning" once their initXXX methods are called. It turns out this is not correct. An NSWindow object is only self-owning once it is displayed, because only then can it receive the 'close' message.
This means that the following code is correct (thanks to Quentin Carnicelli for this test case):
NSWindow* window; window = [[NSWindow alloc] initWithContentRect: NSZeroRect styleMask: 0 backing: 0 defer: YES]; [window release];
Information on how NSWindows are displayed are provided at the following URL:
http://developer.apple.com/documentation/Cocoa/Conceptual/WinPanel/Tasks/OpeningClosingWindows.html#//apple_ref/doc/uid/20000226
The fix is to enhance the retain/release checker to also track the "displayed" state of an NSWindow object and only consider an NSWindow object being self-owning once it is displayed.
This problem is also tracked by: rdar://problem/6062711