I dont know why this is giving memory leak in xcode 4.2. Since I didn't alloc eventArraySave do I need to release it? I thought this will be added to the autorelease pool.
//Unarchive in to array
NSMutableArray *eventArraySave = [NSKeyedUnarchiver unarchiveObjectWithFile:savedfilePathName];
Do I need to release it or is there anything wrong in the above code. Also want to stress that I haven't alloced eventArraySave or inited eventArraySave. Thanks in advance :)
You should not release eventArraySave. It will be returned to you with a net retain count of 0 (after autorelease). If you're seeing leaks from this line, then that suggests that you are over-retaining it somewhere else, or possibly that you are over-retaining some object that is contained within eventArraySave (since this is where that object is allocated as well).
The leak tools do not tell you where your mistake is. They tell you where you allocated the memory that was later leaked.
There is nothing wrong with the code you posted.
Leaks is simply telling you that memory was created there, but not released later.
Your task now is to figure out what was supposed to release it, but is not.
Related
I am new to iOS 5 and ARC, so pardon my silly question.
If we use ARC in our project, does it mean that there wont be any memory leaks at all.
Is there a need to use Instruments for detecting memory leaks and NSZombies if we use ARC?
ARC will help you eliminate certain types of leaks, because you won't forget to release or autorelease single objects. For example, this type of error becomes impossible:
myLabel.text = [[NSString alloc] initWithFormat:#"%d", 17];
// oops, just leaked that NSString!
However, ARC will not eliminate leaks caused by retain cycles. It's still up to you to eliminate retain cycles, either by using weak references or by manually breaking the cycles before they become leaked. For example, as we start to use blocks more, block/self retain cycles become much more common. The Transitioning to ARC Release Notes discuss how to avoid these cycles using weak references.
No, that does not prevent memory leaks from happening. What happens in runtimes with reference counting, is that sometimes your code leaves dangling references, and then objects are not freed. It's still up to you to write good code.
If we use ARC in our project, does it mean that there wont be any memory leaks at all.
There may still be leaks -- In your program, and in the libraries you use. As well, ARC only applies to ObjC objects - you can easily leak any heap allocation which is not an objc object (e.g. malloc/new).
Is there a need to use Instruments for detecting memory leaks and NSZombies if we use ARC?
Yes. The previous response should detail why your program is not guaranteed to be free of these problems. Also, the compiler can get it wrong if you do silly things, and you can certainly cause problems if don't protect your data properly (e.g. concurrent execution).
i'm developing an iPhone project in which i enabled ARC, and when i run my project with instruments so many places it is showing 100% leak for ex:
-[self.navigationController pushViewController:secondPage animated:YES]; //100% leak
[self loadXML];//100% leak
even if i make secondPage object as nil after pushing and in viewDidUnload the leak docent get resolved. How can i solve these leaks?Any help is appreciated in advance.Thank You.
The Leaks instrument (in Instruments) will tell you exactly what was leaked, where it was created, record the stack, and (optionally) record every reference count operation. Learning to use it proficiently is highly recommended.
I thought that I was really close to release this new App of mine when I ran into a dead end. My code works without memory leaks in the simulator (Xcode 4.0.2) but reports memory leaks on my devices.
I think my issue is related to that I copy an object, because in my troubleshooting attempts I tried without a copy, and then the memory leak goes away (but of course so do my functionality!).
What I do is that I add a number of instances of a subclass of UIView to an array . This subclass(Cities of which cityToAdd is an instance) has two UIViews and some variables that I need to access at a later stage.
If I do this I get memory leaks on my devices:
[arrayOfCities addObject:[[cityToAdd mutableCopy] autorelease]];
But if I do this I don't (but loose functionality)
[arrayOfCities addObject:cityToAdd];
In the subclass I have this to handle the copying:
- (id)mutableCopyWithZone:(NSZone *)zone{
Cities *newCity = [[Cities allocWithZone:zone] init];
[newCity initWithCityName:cityName
onRing:ring
withTimeZone:timeZone
withTimeZoneOffset:timeZoneOffset
withDSTAngle:DSTAngle
andDST:isDST];
return newCity;
}
From Instruments I get this when testing on a device:
and when I drill down on the second row it shows this:
Finally my initWithCityName method (sorry for such a long post!!) I put it as a picture to get the colors and messages from Instruments...
Finally the UIIMage imageNamedUniversal is an extension to give me #2x images on the iPad (but I have tried with the normal imageNamed and get the same memory leaks).
I dont know where to start!! Appreciate any ideas.
Thanks
Why are you calling two initialization methods? You are calling init and initWithCityName....
Two things to consider:
After you add cityView and DSTView as subviews, you can and should release them.
And you are initializing newCity twice in your copyWithZone.
Thanks for fast replies and suggestions. You got me on the right track. The cityToAdd that I added to my array was added several times in a loop, but I kept the alloc and init outside of the loop. Once I moved it inside the loop it works in both simulator and device.
Weird that the simulator don't report that memory leak though...
Again, thanks for your fast replies!
I'm trying to use XCode's Leaks utility to fix some memory leaks in my code. Is there a better and more understandable way to check for leaks with explanations that pinpoint the exact line and/or offer suggestions?
Another question, I'm using AVAudioRecorder in my code in one of my view controllers. Should I load the recorder in viewDidLoad or in viewWillAppear?
If you're using Snow Leopard, have you tried using the static analyzer?
As mentioned, use Static Analyzer as a first line of defense.
It will not find everything.
But here's the problem with what you are requesting of Leaks. Think about what a leak is - a leak is when you have memory, that should have been released, but it is not.
So that means you are MISSING a line of code, that could have been placed anywhere - doing the actual release at the right time. But how could the tool possibly know when something SHOULD have been released?
So instead, the tool does the next best thing. It tells you where the leaking memory was allocated, then from there it's up to you to figure out where the object travelled and when it should actually have been released.
Static Analyzer will find the cases where you should have released in a few lines of code from when you created the object. Anything else, you just need to use Leaks to get a starting point to track down when you need to release something elsewhere.
I'm checking for leaks in Instruments, and I've set to check every second, but no leaks are appearing.
I'm sure there must be some in my app, is there anything which could stop these from appearing? Is there a good way I can create a leak so that I can test if leaks do show up in Instruments?
Thanks!
Creating a leak is easy:
id someObject = [[NSObject alloc] init];
someObject = nil;
Drop some code like that into your app, and you should definitely see a leak show up in Instruments.
You're only going to find leaks with a tool if an object is allocated but no longer referenced. Another type of "leak" is to hold a reference to something that you didn't intend to. This typically happens with a collection like a hash table or a dictionary where key/value pairs get left in the collection that the programmer has forgotten about.
I'm pretty sure as clemahieu postulated, what you are really seeing are over-retained objects - you think you have freed them but they still are being retained.
One quick sanity check for this is to set breakpoints in dealloc and see if the classes you expect to be freed really are.
You can also use the memory tracking Instrument (not leaks) to see what memory is still around - just make sure to select the "created and still living" option to check out just what what objects are still around.