On Tue, Apr 27, 2010 at 2:32 PM, Gary L. Wade
<garyw...@desisoftsystems.com> wrote:
> On 04/27/2010 2:27 PM, "Shawn Erickson" <shaw...@gmail.com> wrote:
>
>> On Tue, Apr 27, 2010 at 2:22 PM, Gary L. Wade
>> <garyw...@desisoftsystems.com> wrote:
>>
>>> Yes, but how would you use those to determine why an Apple framework now
>>> chooses to retain a delegate (I'm referring to one particular one I
>>> discovered), thereby causing a retain cycle? It's not a memory leak in the
>>> sense that Instruments or leaks would ever catch it.
>>
>> If you use the Object Allocations template (with retain tracking
>> enabled) in Instruments then yes you can track down those type of
>> issues easily ... far more easily then trying to probe retainCount in
>> code yourself. I likely have use Instruments to track down every
>> conceivable problem that may make you want to look at retainCount...
>> you don't have to modify any code either.
>>
>>> Calling -retainCount immediately before and after the -setDelegate call is
>>> pretty much the only
>>> way.
>>
>> Simply not true.
>>
>> -Shawn
>
> That's how I found the cause of Apple's bug, but I verified what I was
> seeing by using -retainCount before and after, so yes, that simply is true.
1) If you used Instruments you could track down this issue directly
without modification of code, which was my point and counters your
point of having to use retainCount to find something like this.
2) Your use of retainCount is flawed since how do you know that
setDelegate: (or any method for that matter) isn't written something
like the following (or any of countless other ways that could cause a
temporary retain). Wrapping a call to this method with retainCount
wouldn't account for the autorelease and hence would make you think it
is incorrectly retaining something. If you used instruments you would
get the whole picture and not make an incorrect read on the situation.
- (void) setDelegate:(id)delegate {
...do things...
[[delegate retain] autorelease];
...do things...
_delegate = delegate;
}
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
