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.)


_______________________________________________

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

Reply via email to