[cfe-dev] Memory leak analysis and self destructing objects

Ted Kremenek kremenek at apple.com
Thu Jun 26 11:24:49 PDT 2008

On Jun 25, 2008, at 10:34 PM, Nikita Zhuk wrote:

> I noticed that you've added the support for self-owning objects into  
> lib/Analysis/CFRefCount.cpp in r52741. Thanks! I guess that commit  
> was the "longer response" you were talking about.

I actually was planning on following up with you with an email after  
testing that patch further.  Does it silence the false warnings? (at  
least in the case of NSWindow and its subclasses)

I was also investigating other issues that you mentioned; e.g.  
delegates.  I'm not an Objective-C applications programmer, so while I  
understand much of the concepts and the common idioms, I'm lazily  
learning much of the common design practices.  This makes feedback  
like yours especially useful.

What would help me with such feedback is to always provide concrete  
code examples.  These give me a clear idea of what to implement in the  
static analyzer, and it provides test cases we can put into the test  

> Are there any plans to generalize this checking logic so it could be  
> used with other classes than NSWindow? In my own source code I have  
> several classes which use similar self-ownership semantics as  
> NSWindow, and it would be nice to avoid getting false memory leak  
> reports for objects of those classes.

Absolutely.  My thought is that we can implement an attribute that can  
be affixed to the class interface.  I would need to implement parsing  
support for this in clang, but essentially it would something like this:

__attribute__((checker("objc_owns_self"))) @interface ....  @end

Of course GCC doesn't recognize the attribute, so it could be wrapped  
in a macro:

#if __clang__
#define OBJC_OWNS_SELF __attribute__((checker("objc_owns_self")))

and do the following in your code:

@interface ....

Does this sound like a reasonable strategy?  Your feedback is  
invaluable here. (you're basically driving this feature!)

What would help me is also some code examples illustrating the idiom  
of self-ownership.  That way I know I'm solving the right problem.

> As completely offtopic question, does cfe-dev mailing list has some  
> rules which specify when one should reply to mailing list and when  
> to reply just directly to the original poster? I didn't find any  
> rules at general mailing list page at [1]. I've seen both behaviors,  
> and I would like to follow the correct one.
> [1] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> - Nikita

I think the rule of thumb is to keep a conversation on the list, so  
that it is archived and allows other people to wade in.  As long as  
the conversation stays clang related it is on-topic.  I take things  
off list when it comes down to issues only involving two people (e.g.,  
how to send a particular patch over email to a specific person,  
etc.).  Most of the time the communication can be on the list itself.   
For example, the email that you just sent me could have gone directly  
to the list as is.  In fact, I've CC'ed cfe-dev on this reply so that  
this can again become an active thread.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20080626/31a1f898/attachment.html>

More information about the cfe-dev mailing list