Re: Question about Cocoa leaks
Re: Question about Cocoa leaks
- Subject: Re: Question about Cocoa leaks
- From: Laurent Daudelin <email@hidden>
- Date: Sun, 06 Mar 2011 23:08:49 -0800
On Mar 4, 2011, at 19:50, Quincey Morris wrote:
> On Mar 4, 2011, at 17:54, Laurent Daudelin wrote:
>
>> So, can anybody explain what is going on here and whether I should be concerned by those leaks? For each heapshot, I scan 31770 items on disk and each heapshot results in between 8.84KB and 16.97KB leaked each time. The other strange observation is that there are exactly 14 instances of NSPathStore2 and 14 instances of CFString that are leaked in each heapshot even though the loop where the instructions above come from is iterated about 2,200 times. Basically, I scan the folder with 31,770 items in it and will retain 2,200 items of it that I process further.
>
> What's the real question here?
>
> As pathology, leaking 8-16KB doesn't rate very high. I'm not suggesting you ignore this, but the detective task is (possibly) of a far subtler order than looking for something that's sucking up all of the system memory. (IIRC, you started this because each disk scan appeared to be consuming 300KB+ of memory. Did that problem go away?)
>
> What proportion of the 8-16KB is accounted for by the 14 instances of NSPathStore2 and CFString? All of it? If not, what is the rest of it?
>
> One of the list displays (sorry, I don't remember offhand which instrument, either Allocations or Object Graph, I think, but it's one of the choices from the popup just above the detail list) shows you the roots -- the objects that are keeping other objects alive. You *should* be able to track down what's keeping these 28 instances alive from there. If it's not your code, you'd probably be justified in ignoring them.
>
> What sort of object do you keep 2200 instances of, and do they have strong references that could be keeping other things alive? Do the 2200 instances disappear after each run as they should?
>
> Cocoa classes do leak things occasionally. It's just that small leaks don't necessarily get noticed, presumably depending on when in the internal testing cycle they get introduced. (There was, notoriously, a not-so-small leak in the Open/Save dialog code in one of the minor Leopard releases which had the unfortunate side effect of keeping some application objects -- NSDocument IIRC -- alive long after they should have been dead.)
Hello Quincey.
Well, not sure if you were of some inspiration but after reading your message, I found the small leak I was after. My tableview method that returns an object value for a row had been converted from returning a value for each possible tablecolumn into putting that value into a temp variable that is now returned at the end of the method. While converting, I forgot one instance where I was still returning a value there, instead of putting it in my temp variable. Because of this, one instance of NSFileManager was not released at the end, causing all the other instances of CFDate, CFString, etc. to leak.
Now, although the heapshots still show some leaks, they are all events, core graphics things, and other stuff and the leaks are very small. There was even one heapshot that had 0 byte!
I had to restart my Mac (MacBook Pro with 4GB of RAM) in order to be able to run Instruments without it slowing too much. At each run, I instantiate and free over 31,000 instances and after 7 or 8 runs, Instruments has exhausted all free memory and with the timing I do, I see that it starts slowing down everything.
Thanks again! I'll sleep better tonight ;-)
-Laurent.
--
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/
Logiciels Nemesys Software 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