I am trying to analyse the leaks using instruments in Xcode. Here is a sample code I am trying with.
+(NSString *) getUniqueFileName
{
NSDate *time = [NSDate date];
NSDateFormatter* df = [NSDateFormatter new];
[df setDateFormat:#"MMddyyyyhhmmssSSS"];
NSString *timeString = [df stringFromDate:time];
NSString *fileName = [NSString stringWithFormat:#"%#", timeString ];
//[time release];
// [df release];
// [timeString release];
return fileName ;
}
I am using this method every time to generate a filename whenever I capture a photo. All variable are local to his method. If I try to release time, df, timestring, after getting filename, I am getting message sent to deallocated instance. I was sure that if I don't release these variables, memory will be leaking. I tried with instruments and got the following result, and here it is.
Now my question is what is meaning of red color highlighted row with 79.6%? And 20.4% with yellow color row highlighted? Red in general would be dangerous. but what % shows? How it is getting calculated? and when I check call tree, I will get a column named "Leaks" for perticular methods and will contains 100, 234, 560, 2345, some number. What does this number speak about. Help me out. Will be thankful if anyone can provide me good links for understand about instruments.
To explain the percentages in your screenshot, 79.6% of the leaked memory allocated in getUniqueFileName: was allocated in the red line of code. 20.4% of the leaked memory allocated in getUniqueFileName: was allocated in the yellow line of code. Red indicates a high percentage. It may or may not be dangerous.
To explain the Leaks column, it tells you the number of leaks in the method and any functions that method calls. It does not necessarily mean there are that many leaks in the method itself. For example, Cocoa and Cocoa Touch apps start with a main() function. If the main() function has the value 100 in the Leaks column, it means the app has 100 memory leaks, not that main() has 100 leaks.
If you use ARC, disable it to your class, when leaks are creating - now you can release your variables:
Or you can try create your date formatter like this:
NSDateFormatter *df = [[NSDateFormatter alloc] init];
Related
I have started out with Objective-C recently and trying to understand the memory management. I came across a peculiar problem yesterday which was causing a memory leak of over 150MB! I traced it down to a piece of code that was creating NSArray literal of NSNumbers. I managed to solve the issue using NSMutableArray (using addObject), but I haven't been able to grasp the concept as to why one method works and the other doesn't. I would love for someone with a better understanding of the memory management to explain the concept behind it so that I can avoid such mistakes in the future.
To better illustrate my question, let me also provide the code snippets. So for instance, I have a function that creates a NSArray of few NSNumbers and returns it and it gets called many times:
-(NSArray *)getNSNumberArray
{
float num1 = 23.56;
float num2 = 75.34;
float num3 = 223.56;
NSArray *numArray = #[[NSNumber numberWithFloat:num1], [NSNumber numberWithFloat:num2], [NSNumber numberWithFloat:num3]];
return numArray;
}
-(void)causeMemoryLeak
{
for (int i = 0; i < 2000000; i++)
{
NSArray *recieverArray = [self getNSNumberArray];
}
}
This results in memory being occupied to be more than 200MB on an iphone6. However if I change my function to be:
-(NSArray *)getNSNumberArray
{
float num1 = 23.56;
float num2 = 75.34;
float num3 = 223.56;
NSMutableArray *numMutableArray = [[NSMutableArray alloc] init];
NSNumber *nsNumber1 = [NSNumber numberWithFloat:num1];
NSNumber *nsNumber2 = [NSNumber numberWithFloat:num2];
NSNumber *nsNumber3 = [NSNumber numberWithFloat:num3];
[numMutableArray addObject:nsNumber1];
[numMutableArray addObject:nsNumber2];
[numMutableArray addObject:nsNumber3];
return numMutableArray;
}
-(void)causeMemoryLeak
{
for (int i = 0; i < 2000000; i++)
{
NSArray *recieverArray = [self getNSNumberArray];
}
}
This does not cause any memory issues.
Maybe I am missing something very obvious, but still cant figure out the reason behind this. Would really appreciate the help on this. There could also be better ways of doing it, and such answers are welcome but basically I am looking for an explanation behind it.
Many thanks in advance!
Attaching links to screenshots showing the memory allocation on device (iphone 6) (I can not attach images here as of now, so have to provide links)
Approach 1 Memory Allocation (memory is retained and not freed up): https://drive.google.com/open?id=0B-a9WJSBuIL4bTR5RTVuaWpqYkE&authuser=0
Approach 2 Memory Allocation (memory is freed up and there is no surge in memory allocation as well): https://drive.google.com/open?id=0B-a9WJSBuIL4QzQzbGYyQzZDdW8&authuser=0
I tried your code because I really didn't found any reason for memory leak and there is no memory leak.
When you use the regular array, the device runs all the code, and releases the memory only at the end. This causing the heap to alloc 250 MB, and release them at the end.
If you use the mutable array, the device releases the previous array before creating the new one, so there is no point with to many allocation.
I guess that the different may be caused by run time complexity of the called function in the loop.
As you are saying, only one approach is causing surge in memory, it does not seem so. According to the documentation, NSMutableArray uses slightly more memory because it can change size, it can't store the contents inside the object and must store a pointer to out of line storage as well as the extra malloc node for the storage.
In both the approaches, memory is freed up instantly, there is no issue with me.
Update 1 :
I have noticed that if you use the array, for example if you log the array, the memory is freed up instantly in your first approach. It is happening as you do not use that array. It solves your problem.Try this code :
-(NSArray *)getNSNumberArray
{
float num1 = 23.56;
float num2 = 75.34;
float num3 = 223.56;
NSArray *numArray = #[[NSNumber numberWithFloat:num1], [NSNumber numberWithFloat:num2], [NSNumber numberWithFloat:num3]];
return numArray;
}
-(void)causeMemoryLeak
{
for (int i = 0; i < 2000000; i++)
{
NSArray *recieverArray = [self getNSNumberArray];
NSLog(#"%#", recieverArray);
}
}
First, you need to read up on "autorelease" and "autorelease pools". Objects often are kept inside an autorelease pool and only disappear when the autorelease pool disappears. So a loop iterating two million times without using an autorelease pool is a bad, bad idea. You don't actually have a memory leak, the objects will all be released some time after the method returns.
Most methods returning objects return autoreleased objects, but the result of [[xxx alloc] init] is not autoreleased, so there you have the difference. But also ARC is quite clever, and if a method returns an autoreleased object and the caller immediately retains the object, the object will not actually be added to the autorelease pool. That's what happened when the object was passed to NSLog; in order to do that, it had to be retained first. No autorelease pool. In your code, the object was never used, so that optimisation didn't happened.
Of course your code is really useless, so you were punished for writing useless code.
I have one property say
#property(nonatomic,assign) NSString *str;
Now I am having something like
self.str = [[NSString alloc] init];
self.str = #"test";
NSLog(#"%#",str);
[self.str release];
When I run I can see a leak "Potential leak of memory".
Why its showing me leak ?
Please guide me I am leaning phase of iOS
In other words (I'm just expanding on Anoop's answer here), you have two strings, not one.
self.str = [[NSString alloc] init];
self.str = #"test";
The thing on the right side of the first line is a string: [[NSString alloc] init]. But in the second line you throw it away, replacing it with a different string, namely #"test". Now there is NO REFERENCE pointing to the first string. Thus it leaks, since it can never be released nor can anything else ever be done to or for it.
The situation of the string created in the first line is, after the second line, like the situation of "thing1" in the second panel of this diagram:
No one is pointing to it, so its memory cannot be managed, and it lives forever in isolation (leak).
self.str = [[NSString alloc] init]; //1st
One string is allocated not used.
self.str = #"test"; // 2nd
Another constant string "test" is allocated but released.
So first one is a leak.
When you use factory method or create object using alloc,new,retain,copy,mutableCopy your object has +1 retain count every time. You own object in this case. You are responsible for releasing it. So you need to release object after you finish using object which cause -1 retain count to object.
It is not necessary to alloc you string again as you are already creating its property.
And it has its getter setter + you are allocating it again so gives you a leak.
I am fairly new with Objective-C memory management and although I thought I understood it, I have a problem that I cannot manage to solve.
I have this property:
#property (nonatomic, retain) NSDate *dateDisplayed;
that I assign in my viewDidLoad with a custom method:
self.dateDisplayed = [self dbDateFormatToNsDate:#"15/11/2011"];
My dbDateFormatToNsDate method looks like this:
- (NSDate *) dbDateFormatToNsDate:(NSString *) date {
NSDateFormatter *d = [[NSDateFormatter alloc] init];
[d setDateFormat:#"dd/MM/yyyy"];
NSDate *toReturn = [d dateFromString:date];
[d release];
return toReturn;
}
So it returns an autoreleased object (if NSDate follows the convention). But when I get out from viewDidLoadin another function trying to read dateDisplayed:
[dateDisplayed isEqualToDate:[self dbDateFormatToNsDate:#"15/11/2011"]]
I get an NSZombie exception. Thanks for any help!
When assigning using self.property the property is retained because the setter methos is called but when just assigning without using self. it isnt. Assuming of course that you have retain in the propery definition of the .h file.
You could [d autorelease]; instead. I might be totaly off on this, but the toReturn NSDate might need to keep the formatter around even after youve released it, causing the bad access:
Try:
- (NSDate *) dbDateFormatToNsDate:(NSString *) date {
NSDateFormatter *d = [[NSDateFormatter alloc] init];
[d setDateFormat:#"dd/MM/yyyy"];
NSDate *toReturn = [d dateFromString:date];
[d autorelease];
return toReturn;
}
Since you are returning an object created by a method that does not start with alloc, copy, mutableCopy, convention says you should autorelease it.
Autorelease means that it will be release in the future. If the caller of the method needs it to stick around, then they will retain it.
Read the memory management guide:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemoryMgmt.html
Here's the rules:
1 & 3 apply to that method. 2 applies to a calling class that may need to hold it.
1 - You own any object you create
You create an object using a method whose name begins with “alloc”, “new”, “copy”, or “mutableCopy” (for example, alloc, newObject, or mutableCopy).
2 - You can take ownership of an object using retain
A received object is normally guaranteed to remain valid within the method it was received in, and that method may also safely return the object to its invoker. You use retain in two situations: (1) In the implementation of an accessor method or an init method, to take ownership of an object you want to store as a property value; and (2) To prevent an object from being invalidated as a side-effect of some other operation (as explained in “Avoid Causing Deallocation of Objects You’re Using”).
3 - When you no longer need it, you must relinquish ownership of an object you own
You relinquish ownership of an object by sending it a release message or an autorelease message. In Cocoa terminology, relinquishing ownership of an object is therefore typically referred to as “releasing” an object.
4 - You must not relinquish ownership of an object you do not own
This is just corollary of the previous policy rules, stated explicitly.
I need few clarification in iPhone memory management.
Here is an example for setters;
1).
-(void)setValue:(NSString*)input{
[value autorelease];
value = [input retain];
}
In this example, why we have to use autorelease?
Can we use like as follows?
if(value)
[value release];
value = [input retain];
In the first example, Why we should not release the memory for input
2).
If I use following statement; what is the retain count for value
NSString *value;
value = #"welcome";
After the above statement, just I am trying to set one more value. Then what will happen?
eg:
value = #"For testing";
3).
What is the different between 2) and 3)?
NSString *value;
value = [input1 retain];
...
...
value = [input2 retain];// Now what is the retain count for value
4).
If I use following statement, why the app is getting crash?
NSString *value = [[[NSString alloc] init] autorelease];
...
...
Thanks in advance..
If "input" is the exact same object as "value" then calling [value release] could dealloc the object. So you must retain the new input value, release the old value, then assign the new value to the ivar:
[input retain];
[value release];
value = input;
After each of 2) and 3), the NSString *value points to a literal NSString object, the retain count will be 1 in each case, and releasing it is probably not a good idea
After this code:
value = [input2 retain];
value is an alias to the input2 object. The thing to realize is that objects have retain counts, variables do not.
As for your last case,
NSString *value = [[[NSString alloc] init] autorelease];
It creates an autoreleased empty string. If you reference that object again once the autorelease actually happens, you may get a crash because you'll be referring to an object that doesn't exist any more.
If you release a value before you retain the new value then you can have problems if the same value is being set twice. This happens if the caller hasn't retained their own copy, such as when they get the value from the same object they try to set it on, like this:
object.value = object.value;
That statement will cause the object to be released before it's retained again which could lead to the memory being deallocated and result in a dangling pointer being retained. By doing the autorelease it ensures that copying the same pointer onto itself will work correctly.
I usually write my setters as
- (void)setValue:(NString *)input {
if (value != input) {
[value release];
value = [input retain];
}
}
which avoids the problem of input and value both being the same object. If you just release it without checking then you might completely free it and the next line will try to retain an object that doesn't exist anymore.
However, it's best practice to copy strings instead of retaining them :)
(assuming you're working in a non-gc env)
1) you can create a temporary variable and release the temp after the retain/assign. otherwise, you'd need to compare the pointers. deferred release may also mask threading errors (whether you consider that good or bad is...)
2) technically, the NSString literals are valid for the life of your program. that is: while (1) [#"why won't i die?" release]; yields an infinite loop.
3) with explicit retain, alloc+init, new, and copy, you must counterbalance the retain count using release or autorelease. since you did not release value1, the static analysis may (correctly) spot that as a leak. since the string constants never die, the two aren't comparable in this regard.
4) there's nothing wrong with that staement. the problem lies elsewhere in your program. either you are assigning it to an ivar without retaining, or releasing it later.
try using static analysis often, and try reducing how much you use autorelease (you can't avoid it entirely).
none of this is magic, but you can at least reduce the location of many problems to the callsites (or very close) by not using autorelease all over the place. just use manual retain/release where possible.
lastly, check for leaks and run with NSZombies enabled.
1)
You will have to do autorelease because of the following:
When input is the same object as value and you will release value it's retain count will reach zero and get deallocated before you can retain it again though the input.
You can do it with retain but you have to change your code:
-(void)setValue:(NSString*)input{
if (value != input) {
[value autorelease];
value = [input retain];
}
}
2)
I believe #"Text" will be treated as a constant. When you want a object which you do not want any memory management with use:
NSString *value = [NSString stringWithString:#"Text"];
This will return an autoreleased object.
3) In this example it is not about the retain count of value, but about the retain count of both objects where value one is referenced to.
When you dont release input1 before you leave that method, you will have a memory management problem.
4) This statement should work. No points to argue. You rather use [NSString string].
Note:
For memory management: when you use alloc new or copy, you also have to use release or autorelease on the same object in the same scope.
I have the following code below that is meant to change a class var called "today" forward or backward by one day. It will work one time but then after that it crashes. It will do the same no matter if I press the left button or right button. What am I doing wrong?
the var today is a class var initiated as .. today = [NSDate date]
Here is the method that crashes:
(IBAction)changeDateByOne:(id)sender{
NSDate *newDay;
NSDate *currentDay = today;
NSTimeInterval secondsPerDay = 24 * 60 * 60;
if(sender == leftButton){
newDay = [currentDay addTimeInterval:-secondsPerDay];
}else if(sender == rightButton) {
newDay = [currentDay addTimeInterval: secondsPerDay];
}
today = newDay;
}
Not only do you need to retain the date created, but you also need to release the existing value held by "today," otherwise you'll leak the old reference.
When initializing the instance, use:
today = [[NSDate date] retain];
I would change the last line to:
[today release];
today = [newDay retain];
And finally, in your dealloc method, add:
[today release];
before calling [super dealloc];
You need to read the memory management documentation. That’s here:
http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html
If you’re adding or subtracting days, you might want to read this which is an alternative way of doing the same thing:
http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/DatesAndTimes/Articles/dtCalendricalCalculations.html#//apple_ref/doc/uid/TP40007836-SW1
Lastly, if something crashes, it’s often helpful to look at the back traces (and include them in your questions if you can’t figure it out for yourself). Memory management bugs are usually the problem if you see objc_msgSend (or one of its companions) in the trace.
Maybe you need to say
today = [[NSDate date] retain]
I think you need to retain the newDay object returned from the addTimeInterval method. You may also need to release today before you do the assignment at the end.