I know that you think I'm some noob at this. This may be true, but I am aware that Instruments shows that the memory I allocated during that distributed notification is still there. I know this because it's a 9MB allocation and it's in a NSData with no copy bytes and free when released. The one thing I may not understand is when things are released and when they are shown to be released in instruments. I should play around in a test application with allocing things, but from what I can think of it's not being released as it shows it as alive in instruments. The way programming works is there is a run loop in the main of the application and in that run loop they create a autorelease pool, when there is an event, it will call the right object for that event and run the right method for the event, after the event runs, it'll drain the autorelease pool and continue to listen for more events. That's my understanding and I think that when you drain the autorelease it would release ALL objects that was added to it and when the retainCount reaches 0, it'll free it from memory. Now this all makes sense to me, if it doesn't work this way, I don't understand how it works and would appreciate it if someone told me what it actually does.
On Feb 18, 2011, at 4:01 PM, Fritz Anderson wrote: > You're thrashing around for an explanation for something that I don't think > needs explaining. > > How do you know "memory is not autoreleased?" What do you mean by that? If > it's simply that the retain count isn't what you expect, forget it. Forget > retainCount is in the API; if your situation tempts you to look at > retainCount, retainCount is almost guaranteed to be misleading. The OS has > the right to retain, and later release, any object at any time. So long as > you and the OS both obey the memory-management rules (which means, on your > part, not sprinkling releases and drains whenever you're in doubt), the > object will be deallocated when you and the OS are both done with it. > > That Instruments doesn't show "these allocations" (what allocations?) as a > leak raises a strong presumption that it isn't a leak. Your attempt to plug a > leak that isn't there will crash your application. > > You application, the other application, and the OS all have their separate > memory spaces and heaps. You (and therefore the retain/release logic for your > application) have no access to any heap but your own. It doesn't matter > whether the other application has retained its copy (note: copy) of its > object. You're looking at your own copy. > > — F >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
