• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: menu madness with retain count
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: menu madness with retain count


  • Subject: Re: menu madness with retain count
  • From: Shawn Erickson <email@hidden>
  • Date: Tue, 27 Apr 2010 14:46:42 -0700

On Tue, Apr 27, 2010 at 2:32 PM, Gary L. Wade
<email@hidden> wrote:
> On 04/27/2010 2:27 PM, "Shawn Erickson" <email@hidden> wrote:
>
>> On Tue, Apr 27, 2010 at 2:22 PM, Gary L. Wade
>> <email@hidden> 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 (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

  • Follow-Ups:
    • [Moderator] Re: menu madness with retain count
      • From: Scott Anguish <email@hidden>
    • Re: menu madness with retain count
      • From: "Gary L. Wade" <email@hidden>
References: 
 >Re: menu madness with retain count (From: Shawn Erickson <email@hidden>)
 >Re: menu madness with retain count (From: "Gary L. Wade" <email@hidden>)

  • Prev by Date: Re: NSApplicationMain question
  • Next by Date: Re: NSApplicationMain question
  • Previous by thread: Re: menu madness with retain count
  • Next by thread: Re: menu madness with retain count
  • Index(es):
    • Date
    • Thread