On Oct 3, 2009, at 2:38 AM, Rick C. wrote:
i'm having a few memory issues where my memory climbs over time although using leaks it shows i have no leaks.
Leaks aren't the only way to use excessive memory. For example, if you keep allocating objects and putting them in a collection somewhere (like the mutable arrays you describe below) but never use them and your code effectively forgets they are there due to a logic error, they haven't officially leaked but the effect is similar.
You can use the Object Alloc instrument. When examining the recorded data, you can select a range of data. Set its beginning to a point in time after your app should have reached equilibrium -- after it has set up those objects which are meant to stick around for the whole lifetime or your app. Set the end of the range to any point afterward where the memory use has inexplicably risen. Tell the instrument to show only the still living objects. This effectively shows you objects which were allocated and expected to be temporary, but which are still around.
1. i have a handful of mutable arrays that i need for the lifetime of my app. i alloc/init them upon startup and at various places i do removeAllObjects and then addObjectFromArray with the other array being convenience created. in dealloc i do release.
So long as you really are invoking removeAllObjects when you expect to be, and the other array only contains what you think it should, that sounds fine.
2. i use NSObject performSelectorInBackground for a few methods so they do not tie up my main thread. one of these background methods uses NSTask. in every background method i init the autorelease pool and release it according to the docs. i also release the NSTask i use.
There have been reported issues with NSTask: if you don't run the run loop of the thread from which it was created and launched, then it might not clean up its resources. -waitUntilExit should be sufficient. If you're not waiting for the NSTask to complete, then there's little reason to launching it from a background thread. So, you might be better of launching it from the main thread, where there's extra effort required to make sure the run loop is run. In fact, you can always use an NSTask from the main thread in an asynchronous fashion, and that may be a better design choice, depending on what else your background thread is doing.
and i do modify a few of the above mentioned mutable arrays in these background methods in the way i described above.
I hope you're being careful to properly guard against multiple threads accessing any given mutable array at the same time.
i'm trying to pinpoint where the problem can be and it seems everytime i initiate performSelectorInBackground my memory usage goes up and is not reclaimed. i know starting a new thread increases memory but i'm expected it to be reclaimed.
Of course, you have to allow the thread to exit by returning from the method named by the selector. I assume you know that. :)
Does Activity Monitor show the thread count of your app steadily rising, or does it fall back to equilibrium when it should?
Regards, Ken _______________________________________________ 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
