[FP] RetainCount: NSWindow delegate autorelease of NSWindowController

[llvmbot]

Bugzilla Link	2633
Version	unspecified
OS	MacOS X
Attachments	Xcode project for Mac OS X
Reporter	LLVM Bugzilla Contributor
CC	@tkremenek,@haoNoQ

Extended Description

Clang Static Analyzer (build 71 August 2, 2008) detects a Memory Leak in Objective-C source code. It seems to be a false positive.

You can follow these steps to reproduce the problem:

• open the Xcode project
• run the application
• choose "New Sample Window" from the "File" menu
• it calls openSampleWindow in MainClass.m
• it allocates a SampleWindow object (it's a NSWindowController subclass)
• it displays the window
• you can click the window close button
• it calls windowWillClose in SampleWindow.m
• the window controller is autoreleased and the window is released
• you can check the log, the SampleWindow object is deallocated

Clang Static Analyzer detects a memory leak in MainClass.m

I have found this technique in Apple documentation:
http://developer.apple.com/documentation/Cocoa/Conceptual/Documents/Concepts/WindowClosingBehav.html
If you want closing a window to deallocate the window and its window controller when it isn’t owned by a document, you should add code to the object that does own the window controller to observe the NSWindow notification NSWindowWillCloseNotification or, as window delegate, implement the windowWillClose: method. When you see that your window controller’s window is closing, you can autorelease the window controller, which will also have the effect of releasing the window and any other top-level objects loaded from the window controller’s nib file when the application reenters the main event loop.

Clang Static Analyzer detects a memory leak because the object is allocated in MainClass.m and it is autoreleased in SampleWindow.m when windowWillClose is called.

Do you think you can improve Clang Static Analyzer? or do you think autoreleasing the NSWindowController in windowWillClose is a bad design?

Thanks

[llvmbot]

assigned to @tkremenek

[tkremenek]

I have found this technique in Apple documentation:

http://developer.apple.com/documentation/Cocoa/Conceptual/Documents/Concepts/WindowClosingBehav.html
If you want closing a window to deallocate the window and its window
controller when it isn’t owned by a document, you should add code to the
object that does own the window controller to observe the NSWindow notification
NSWindowWillCloseNotification or, as window delegate, implement the
windowWillClose: method. When you see that your window controller’s window is
closing, you can autorelease the window controller, which will also have the
effect of releasing the window and any other top-level objects loaded from the
window controller’s nib file when the application reenters the main event
loop.

Clang Static Analyzer detects a memory leak because the object is allocated in
MainClass.m and it is autoreleased in SampleWindow.m when windowWillClose is
called.

Do you think you can improve Clang Static Analyzer? or do you think
autoreleasing the NSWindowController in windowWillClose is a bad design?

Mikael:

This is an idiom that I would like the analyzer to handle directly one day. Unfortunately in general it requires analysis across .m files (inter-procedural analysis). This is something we are 100% committed to doing, but it will be a featured rolled out over time (there is no quick fix). You're bug report provides an excellent test once we get IPA off the ground. Thanks so much for this test case. It is extremely helpful.

[llvmbot]

In the mean time, it would be nice to have builtins or __attribute__s to deal with isolated incidents without terrible hacks or without having to turn off scan-build (and thus getting rid of checking for the rest of the code).

[haoNoQ]

Ugh, this false positive is still there. And while we did get inter-procedural analysis implemented, we never got it to work across .m files ("cross-translation-unit analysis").

Yes, this could be addressed via annotations or by adding more hacky suppressions into the checker.

Tracking internally as rdar://problem/46926237.