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 detectors. Michael David Crawford P.E., Consulting Process Architect [email protected] http://mike.soggywizard.com/ One Must Not Trifle With Wizards For It Makes Us Soggy And Hard To Light. On Fri, Sep 4, 2015 at 9:13 AM, <[email protected]> wrote: > 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 <[email protected]> >> wrote: >> >> 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. >> Typically, I see an item "CFArray (mutable-variable)" incrementing its >> #Persistent once a second, and an item "Malloc 32 Bytes" incrementing by 2 >> every second. The Leaks tool shows nothing. Taking Generation snapshots at >> intervals of a second or two shows the steady accumulation of small >> allocations, described as <non-object>. >> >> I'm using XCode 6.4 and running this in the simulator for iPhone 6 and iOS >> 8.4. I've also tried the iPad2 and iOS 8.4 with similar results, although >> there the item that ticks up and up is "Malloc 64 bytes", at a rate of about >> 1 KB every 5 seconds. The project is compiled with ARC turned on. The high >> water mark of total memory use displayed in XCode increases by a megabyte in >> something over an hour and an overnight run shows no sign of it stopping. >> >> But I cannot see what is causing this. It's a very small app, and if I let >> it run without interacting with it, the only code it executes is the >> following method of the single view controller, invoked by an NSTimer once a >> second to update a display of the time. >> >> - (void)updateTime { >> NSDate *now = [NSDate date]; >> double seconds = [now timeIntervalSinceReferenceDate]; >> double intseconds = round(seconds); >> now = [NSDate dateWithTimeIntervalSinceReferenceDate:intseconds]; >> >> [dateFormatter setDateFormat: >> [NSDateFormatter dateFormatFromTemplate:@"jjmmss" options: 0 locale: >> thelocale]]; >> [[self timestring] setText: [dateFormatter stringFromDate: now]]; >> >> [dateFormatter setDateFormat: >> [NSDateFormatter dateFormatFromTemplate:@"EEEdMMM" options: 0 locale: >> thelocale]]; >> [[self daystring] setText: [dateFormatter stringFromDate: now]]; >> >> [dateFormatter setDateFormat: >> [NSDateFormatter dateFormatFromTemplate:@"yyyy" options: 0 locale: >> thelocale]]; >> [[self yearstring] setText: [dateFormatter stringFromDate: now]]; >> } >> >> timestring, daystring, and yearstring are properties of my ViewController >> class connected to labels in the storyboard: >> >> @property (weak, nonatomic) IBOutlet UILabel *timestring; >> @property (weak, nonatomic) IBOutlet UILabel *daystring; >> @property (weak, nonatomic) IBOutlet UILabel *yearstring; >> >> dateFormatter and thelocale are private instance variables, initialised once >> in viewDidLoad(). I've also tried versions where these are variables local >> to updateTime(), and where "now" is an instance variable, but moving these >> around gives the same results. I've also tried, with equal lack of effect, >> splitting up some of the one-liners into things like: >> >> NSString *thestring = [dateFormatter stringFromDate: now]; >> [[self timestring] setText: thestring]; >> >> When the app is in the background it does nothing (it invalidates the >> NSTimer and sets the instance variable holding it to NULL), and Allocations >> reports no activity. >> >> What is causing this problem? Instruments says the Responsible Library is >> libdispatch.dylib, and the Responsible Caller is >> _dispatch_continuation_alloc_from_heap. The names suggest that this may be >> nothing to do with the code above. Google turns up a small number of >> queries regarding memory leaks with similar symptoms, but no answers. >> >> -- >> Richard Kennaway >> >> >> _______________________________________________ >> >> Cocoa-dev mailing list ([email protected]) >> >> 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/dangerwillrobinsondanger%40gmail.com >> >> This email sent to [email protected] > > _______________________________________________ > > Cocoa-dev mailing list ([email protected]) > > 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/mdcrawford%40gmail.com > > This email sent to [email protected] _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
