Re: Analyser reports memory leak… where?
Re: Analyser reports memory leak… where?
- Subject: Re: Analyser reports memory leak… where?
- From: Roland King <email@hidden>
- Date: Thu, 12 Sep 2013 21:16:36 +0800
Creative but no I don't think so.
For a start that's not what the error says, if it cared less what the property setter setEventTypes: did then it would point out that increased the refcount by 1, the release decremented it by 1 and thus there was a net +1 in there. It doesn't do that, it doesn't mention that method at all.
setEventTypes: takes a parameter and returns nothing. What it does with that parameter is entirely up to it, it may retain it if it wishes to be released later, or do any other thing it wants. If the analyser doesn't much like what setEventTypes: is doing, it would complain about setEventTypes:, which it's not doing, it's complaining about a caller. That method doesn't return anything and has no special naming so the analyser will presume it correctly to do nothing net-net to its argument.
-eventTypes doesn't need the new or copy because it does not return an object owned by the caller. Whether the object it returns is already owned by itself to be released later is irrelevant, the refcount has not been increased before return to the caller so the method is correctly named and the analyser can properly assume it to be a +0 method. And apart from that it's not even called in the piece of code in question so that's not really relevant.
If what you wrote were true, and the analyser wandered into void returning methods like property setters which by necessity retain their arguments then it would warn everyone constantly about every property setter and it doesn't. I don't even believe as of 4.6 the analyser does go into methods, I believe this was covered in WWDC 2013.
That code still doesn't have a leak in it and I don't know what about it triggers an analyser bug, but the analyser is just wrong here and it's wrong in a very simple common case. What's possibly even stranger is that the error message about eventTypes not being referenced in that code path is outside the scope eventTypes is even defined, so the thing really is confused. Which leads to one question, there isn't another in-scope variable called eventTypes is there? Static, another iVar, from a superclass, synthethized in some way .. something? If there were then that might explain the confusion (which eventTypes does [ eventTypes release ] refer to in that case).
On 12 Sep, 2013, at 8:00 pm, Bill Cheeseman <email@hidden> wrote:
> I neglected to send this to the list. It's important enough that I think I should.
>
> Bill Cheeseman
>
> Begin forwarded message:
>
>> From: Bill Cheeseman <email@hidden>
>> Subject: Re: Analyser reports memory leak… where?
>> Date: September 12, 2013 6:34:05 AM EDT
>> To: Graham Cox <email@hidden>
>>
>> The -eventTypes method sends the -setEventTypes: message, which retains the object and assigns it to the mEventTypes iVar. Then -eventTypes returns the mEventTypes iVar without autoreleasing it, and -eventTypes doesn't have "new", "copy", or whatever in its name. The release of the eventTypes local variable in -eventTypes only offsets the first retain implicit in the -alloc message in -newEventTypes. The retain count is still +1 at the point where the error is reported.
>>
>> Bill Cheeseman
>>
>> On Sep 12, 2013, at 5:35 AM, Graham Cox <email@hidden> wrote:
>>
>>> Here's some code for which the Analyser reports "potential leak of an object stored into 'eventTypes'". I don't see it.
>>>
>>> I didn't write this code, so I'm reluctant to change it even though I would have written it a bit differently. mEventTypes is an ivar.
>>>
>>> - (void)setEventTypes:(NSDictionary*)eventTypes
>>> {
>>> if (eventTypes != mEventTypes)
>>> {
>>> [mEventTypes release];
>>> mEventTypes = [eventTypes retain];
>>> }
>>> InitializePrefsForEventTypeNames();
>>> }
>>>
>>> - (NSDictionary*)eventTypes
>>> {
>>> if (mEventTypes == nil)
>>> {
>>> [self loadNib];
>>>
>>> NSDictionary* eventTypes = [self newEventTypes];
>>> [self setEventTypes:eventTypes];
>>> [eventTypes release];
>>> }
>>>
>>> return mEventTypes; //<----- analyser complains here
>>> }
>>>
>>>
>>>
>>> - (NSDictionary*)newEventTypes
>>> {
>>> //[code deleted that presets contents of 'eventTypes']
>>>
>>> // Method name begins with "new"; clients are responsible for releasing.
>>> return [[NSDictionary alloc] initWithDictionary:eventTypes];
>>> }
>>>
>>>
>>>
>>> --Graham
>>> _______________________________________________
>>>
>>> Cocoa-dev mailing list (email@hidden)
>>>
>>> Please do not post admin requests or moderator comments to the list.
>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>>
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>> --
>>
>> Bill Cheeseman - email@hidden
>>
>
> --
>
> Bill Cheeseman - email@hidden
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden