Re: Puzzling memory creep

> On 5 Sep 2015, at 02:48, Quincey Morris > wrote: > > On Sep 4, 2015, at 06:25 , Richard Kennaway wrote: >> >> If anyone wants to take a look at the whole project, I've put a zip file at > > FWIW, I don’t see any leaks when I

Re: Puzzling memory creep

> On 4 Sep 2015, at 01:21, Quincey Morris > wrote: > > Two thoughts about this. > > 1. Are you sure that ‘updateTime’ is running on the main thread? It needs to > be, since you’re updating the UI directly from this code. Yes, according to calling

Re: Puzzling memory creep

> On 4 Sep 2015, at 01:11, Scott Ribe wrote: > > On Aug 14, 2015, at 2:29 PM, Richard Kennaway wrote: >> >> the Responsible Caller is _dispatch_continuation_alloc_from_heap > > Sure sounds like something that *might* underly the

Re: Puzzling memory creep

> On 4 Sep 2015, at 01:38, Cosmo wrote: > > Is there any chance you have Zombie checking turned on in your scheme > settings? In my experience that might account for what you’ve described. No, that's turned off. Turning it on records large numbers of deallocated

Re: Puzzling memory creep

On Thu, September 17, 2015 3:32 am, Roland King wrote: > Do you have this problem on an actual device or just in the simulator? > I’m on a later iOS than you, perhaps that makes a difference I see the moderation system has suddenly disgorged all my posts from a week or three ago, just when I'm

Re: Puzzling memory creep

> On 4 Sep 2015, at 16:55, Scott Ribe wrote: > 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

Re: Puzzling memory creep

> > If anyone wants to take a look at the whole project, I've put a zip file at > https://www.dropbox.com/s/relxku0iw44o237/TestUILabelLeak.zip ok I downloaded it and it’s running on my iPhone right now, and instruments is up and it’s not leaking and it’s not growing. Reducing the timer

Re: Puzzling memory creep

On Sep 5, 2015, at 13:41 , Richard Kennaway wrote: > > With a timer interval of 0.01, the MacBook Pro shows about 2 new 32-byte > allocations per second, and the iMac shows about 100 per second. I repeated the test, with that smaller interval, and yes I can see a very

Re: Puzzling memory creep

On Sep 4, 2015, at 7:53 AM, Richard Kennaway 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 >

Re: Puzzling memory creep

So don't create a new for matter every time. Create one once outside of the timer. Formatters are heavy. Beyond that you might try judicious use of @autorelease{} Sent from my iPhone > On Aug 15, 2015, at 5:29 AM, Richard Kennaway wrote: > > I've written an iOS app

Re: Puzzling memory creep

A memory pool will appear to be a leak however pools usually reach a maximum size then stop growing. Such a pool may be an internal implementation detail that is invisible to your client code. I don't know that your leak is really a pool however this is a common false positive for leak

Re: Puzzling memory creep

On Sep 4, 2015, at 06:25 , Richard Kennaway wrote: > > If anyone wants to take a look at the whole project, I've put a zip file at FWIW, I don’t see any leaks when I run your test project. This is with Xcode 7 beta 6 and the iOS 9 iPhone simulator, since that’s what

Re: Puzzling memory creep

Is there any chance you have Zombie checking turned on in your scheme settings? In my experience that might account for what you’ve described. > On Aug 14, 2015, at 1:29 PM, Richard Kennaway wrote: > > I've written an iOS app that, according to Instruments, seems to

Re: Puzzling memory creep

On Aug 14, 2015, at 2:29 PM, Richard Kennaway 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

Puzzling memory creep

I've written an iOS app that, according to Instruments, seems to very slowly allocate more and more memory over time, although I can see no reason for it. After starting it, and letting it settle down, I see in the Allocations tool several entries in the "#Persistent" column creeping upwards.

Re: Puzzling memory creep

Two thoughts about this. 1. Are you sure that ‘updateTime’ is running on the main thread? It needs to be, since you’re updating the UI directly from this code. 2. The code inside ‘updateTime’ is very self-contained, so it seems easy to try a divide-and-conquer strategy. What happens if you