Re: Puzzling memory creep
Re: Puzzling memory creep
- Subject: Re: Puzzling memory creep
- From: Scott Ribe <email@hidden>
- Date: Fri, 04 Sep 2015 09:55:21 -0600
On Sep 4, 2015, at 7:53 AM, Richard Kennaway <email@hidden> wrote:
>
> 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:
I would not be surprised if that callback to an observer is something triggered by your updates--some part of the window event/update/redraw handling deep in the framework. I don't have any advice to offer as to how to get from that suspicion to a solution, sorry. But varying the frequency of your updates, and checking to see if that drives the rate of leakage through the observer callback, will at least establish if it's truly independent or correlated.
If it is correlated, then the prior suggestion of stripping down your update code bit by bit is a good one. I'd make one change though, first I'd remove *all* the code in the NSTimer callback. Find out if simply having a timer fire is enough, or if you have to actually do some updating--then if it doesn't leak with no code, start adding back gradually. And of course if it does leak with no code, you're ready to file a bug report and/or open a DTS incident.
--
Scott Ribe
email@hidden
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice
_______________________________________________
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