> On 4 Sep 2015, at 01:11, Scott Ribe <scott_r...@elevated-dev.com> wrote: > > On Aug 14, 2015, at 2:29 PM, Richard Kennaway <rich...@kennaway.org.uk> 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 (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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
