On Jul 22, 2009, at 10:30 AM, Tarek Khouzam wrote:
So here is my issue. I have an app that when it should have hit the
limit of memory it needs to use, it keeps growing over time.
But after 12 hours or so its memory grows about 10x. So what I would
like to know is where I should go from here? GC should be taking
care of freeing unneeded memory. I can't use the old apps like leaks
because its not valid anymore. Is there a technique or app that can
show me what object is using all the memory
?
Basically I am at wits end. I have tried Instruments but I have a
better chance of reading Chinese then understanding what Instruments
is tell me. Any help would be greatly appreciated.
(This should be on Cocoa-dev)
If you have access to Snow Leopard, use it for your analysis work.
The tool chain on Snow Leopard is vastly improved.
Under GC, you can still create situations that lead to heap bloat (to
the point of causing a crash). Basically, if you have objects that
are rooted -- are referenced by some global object somewhere, a global
NSMutableArray* or a cache or something -- or if you call CFRetain()
(or CF*Create*(), which returns a retained object) on an object and
don't call CFMakeCollectable() or CFRelease().
Your analysis should focus on what is sticking around that shouldn't.
With Instruments, the easiest approach is to use the ObjectAlloc
instrument -- ObjectGraph will work, too, but ObjectAlloc is better
for analyzing overall allocation populations.
Try using the filter field at the bottom and look for whatever it is
that is sticking around that shouldn't be. Given the consistent
growth over time, it should be pretty obvious.
Or you can use the 'heap' command line tool. Take a 'heap' snapshot
shortly after lunch, then again after a few hours and compare the two.
Once you have identified something, anything, that is sticking around,
figure out where it is being allocated and/or retained. This is
easily done with the ObjectAlloc instrument or you can set the
MallocStackLoggingNoCompact environment variable and then use the
malloc_history tool (see the malloc and malloc_history man pages).
b.bum
_______________________________________________
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
