Re: Puzzling memory creep
Re: Puzzling memory creep
- Subject: Re: Puzzling memory creep
- From: Richard Kennaway <email@hidden>
- Date: Fri, 04 Sep 2015 14:53:46 +0100
> On 4 Sep 2015, at 01:11, Scott Ribe <email@hidden> wrote:
>
> On Aug 14, 2015, at 2:29 PM, Richard Kennaway <email@hidden> wrote:
>>
>> the Responsible Caller is _dispatch_continuation_alloc_from_heap
>
> Sure sounds like something that *might* underly the implementation of NSTimer.
>
> Quick experiment: change the delay in your NSTimer creation from 1.0 to 0.1 and see what happens to memory usage ;-)
>
> Also, you are aware that you can get the full stack trace for any allocation, right? (You may have to set an option in the instrument before you start the run, I don't remember.)
_dispatch_continuation_alloc_from_heap occurs just once in the Call Trees display, which simplifies things. The call tree down to that point is:
Bytes Used Count Symbol Name
394.17 KB 100.0% 5851 start
394.17 KB 100.0% 5851 main
394.17 KB 100.0% 5851 UIApplicationMain
394.17 KB 100.0% 5851 GSEventRun
394.17 KB 100.0% 5851 GSEventRunModal
394.17 KB 100.0% 5851 CFRunLoopRunInMode
394.17 KB 100.0% 5851 CFRunLoopRunSpecific
394.17 KB 100.0% 5851 __CFRunLoopRun
376.50 KB 95.5% 5778 __CFRunLoopDoObservers
376.50 KB 95.5% 5778 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__
376.50 KB 95.5% 5778 CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*)
373.75 KB 94.8% 5767 CA::Transaction::commit()
373.75 KB 94.8% 5767 CA::Context::commit_transaction(CA::Transaction*)
354.69 KB 89.9% 5675 CABackingStoreCollectAsync
354.69 KB 89.9% 5675 CA::DispatchGroup::enqueue(void (*)(void*), void*)
354.69 KB 89.9% 5675 dispatch_async_f
354.69 KB 89.9% 5675 _dispatch_async_f_slow
354.69 KB 89.9% 5675 _dispatch_continuation_alloc_from_heap
354.69 KB 89.9% 5675 malloc_zone_calloc
This is after having run for about ten minutes with a timer interval of 0.1 seconds. At this point these stray mallocs account for almost all of the persistent memory allocations.
It appears that __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__
does not relate to my updateTime() being invoked by the NSTimer, because elsewhere under __CFRunLoopRun I see __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__. Below that, the tree reports:
Bytes Used Count Symbol Name
3.56 MB 99.7% 38518 __CFRunLoopRun
70.66 KB 1.9% 102 __CFRunLoopDoTimer
70.66 KB 1.9% 102 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
70.66 KB 1.9% 102 __NSFireTimer
70.66 KB 1.9% 102 -[ViewController updateLabels]
which which seems to account for everything that updateLabels() is doing, and is not where the leak is happening.
Further googling turned up this posting on another forum which looks like the same problem:
http://www.gamedev.net/topic/654285-instruments-and-memory-usage-going-up-without-any-leaks/
But no solutions there. I have ARC enabled, so the mention of autorelease there wouldn't help.
I've found a few other similar postings to various forums spread over many years, but never a solution to them.
Is there some way to find out all of the Observers that are present at run-time? My app certainly does not create any explicitly.
-- Richard Kennaway
_______________________________________________
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