Re: Puzzling memory creep
Re: Puzzling memory creep
- Subject: Re: Puzzling memory creep
- From: Michael David Crawford <email@hidden>
- Date: Fri, 04 Sep 2015 11:18:38 -0700
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@hidden
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@hidden> 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@hidden> 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@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
>
> _______________________________________________
>
> 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
_______________________________________________
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