• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Puzzling memory creep
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: Puzzling memory creep
      • From: Scott Ribe <email@hidden>
References: 
 >Puzzling memory creep (From: Richard Kennaway <email@hidden>)
 >Re: Puzzling memory creep (From: Scott Ribe <email@hidden>)

  • Prev by Date: Re: Puzzling memory creep
  • Next by Date: Re: Puzzling memory creep
  • Previous by thread: Re: Puzzling memory creep
  • Next by thread: Re: Puzzling memory creep
  • Index(es):
    • Date
    • Thread