Can't figure out what's going on here. +array and +dictionary are supposed to be autoreleased correct? Why then is instruments insisting I have memory leaks there?
So I set dictionaries for about 12 or so objects, and then eventually I set the property self.messageObjectsForPage = messageObjects;
Not sure what's happening here.
What I feel is that Instruments is not very precise yet on what it calls as Leaks.
I have been developing apps for more than an year now but I have faced similar issues many times.
Also you are correct that +array and +dictionary creates autoreleased objects.
So as far as the app works fine and doesn't give any memory warnings on device, you can ignore this minor leaks and search for other obvious leaks if they exist.
This is what Apple has to say about NSDictionary's +dictionary method
This method is declared primarily for use with mutable subclasses of NSDictionary.
If you don’t want a temporary object, you can also create an empty dictionary using alloc... and init.
So this assures that it is autoreleased object.
Hope this helps you.
Related
I'm making my first app and it's really confusing.
I am using ARC, and probably ALL of my potential leaks say:
"Object leaked: object allocated and stored in 'point' is not referenced later in this execution path and has a retain count of +1"
They are on almost any object I create using [[alloc] init].
Any suggestions about how to handle those? The app works fine, though.
Thanks.
Are you sure your project is actually set to ARC? Those types of analyzer warnings sound like it isn't. Is this a new project where ARC was automatically turned on for you or did you do the conversion for it yourself?
There isn't a way to actually tell the analyzer that you are ARC or aren't. It will just pick that up from the settings automatically.
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 a little ways into developing my first iphone app, and I've been running into exc_bad_access a lot. (I'm sure it's because I'm not designing stuff in a very MVC-proper way yet.)
It's extremely frustrating trying to hunt down why I'm running into these errors all the time... is there a way in the xcode debugger to keep a watch list of pointers, so you can actually see when various objects are being released? Something, anything that can give me more of a visual understanding of why my program design is flawed?
In particular, I keep having trouble with my "webobject" class I've wrapped all of my NSURLConnection methods in. When I try to call performselector to the view controller that initiated a "webobject" request, I keep getting exc_bad_access when I try to access the webobject's synthesized properties. Is there something fundamentally wrong with my notion that I should wrap all of my webservice-related methods into a class that I can import anywhere?
Dave,
I don't know of a way to trace the deallocation of objects (especially native objects like NSStrings). But, I experienced a similar abundance of exc_bad_access messages when starting Objective-C programming. But one day I read something that helped me alot to get rid of these messages:
If you create an object using alloc, copy, or a method that begins with new, then it is your object to manage and dealloc. You can call retain and release and that cycle will work as expected on those objects. If you never call release or dealloc on it, it will hang around foreever and be a leak. If you call a method that is something like 'stringWithFormat', numberWithYadaYada then that object is set for autorelease. Meaning, as soon as you exit the method that is using it, it may get dealloced. Therefore, if you've called one of these autorelease methods, you must retain it if you want to see it later on.
I suspect that either your delegate or NSURLConnection is getting autoreleased, that is the cause of your bad access messages.
Jack
You could try creating a breakpoint on -[NSObject dealloc] (or the same method on the subclass you are targetting).
I would also refer you to one of the many Cocoa memory handling tutorials.
I ended up reading up about NSZombieEnabled, which has helped me track down those exc_bad_access messages. More info here: http://www.cocoadev.com/index.pl?NSZombieEnabled
Just as a general thing, you should run as a static analyzer and it will probably tell you when you are over or under retaining objects.
pertinent stackoverflow question
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.
I need lessons in memory management. I have an application that uses multiple views (around 10), some of these are attached to tab controller. Problem is that I'm using images (many images that I load from a web service). I'm facing the following issues.
The memory keeps increasing when I scroll in the table view (why?) - I checked the CustomTableViewCell application from Apple's site, and it's showing the same signs when I run it with Instruments.
I'm using autorelease with many objects, but I see that these objects don't actually get released and the memory is wired. How can I get rid of these objects?
How can I tell the NSAutoreleasePool to periodically release the objects that are not being used? I think this can help me get rid of wired memory. But can I do that?
Is there any example by Apple or someone else (book or online articles) explaining how to use Instruments (in a little detail with example?) and to fine tune the application for memory and performance?
Thanks.
Now that we have the "just say no" answers to autorelease out of the way, I thought I'd add a tip on how to use autorelease more effectively. For better or worse not everyone's going to completely avoid autorelease-- if for no other reason than because Apple provides so many convenience methods that hand you autoreleased objects.
You can't just tell the autorelease pool to free up any objects that you're not using. There's no garbage collection, and how else is it going to know?
What you CAN do is to create a local autorelease pool and then release that when you no longer need the local autoreleased objects. If you have a block where you're creating autoreleased objects, you'll ensure they get freed by creating a local autorelease pool at the start of the block (just alloc/init it, no magic required) and then releasing the pool at the end of the block. And voila, and objects in the pool are also released.
Autorelease pools nest, so keep that in mind if you do this. If you release an autorelease pool, make sure it's the most-recently-allocated pool and not some other one.
The autoreleased memory is released when control is returned back to the system, but only when it chooses to. If you wish to force memory to be released use "release" which works there and then.
It should be noted that because of memory fragmentation that allocating and deallocating a block of memory may not seem to get you back to where you started in terms of measurable "free" memory.
Tony
For performance reasons, Apple recommends that you retain/release objects yourself whenever possible. autoreleasing them can cause excess memory usage as the autoreleased objects aren't always released immediately.
In other words, if you know you're done with an object, explicitly release it.
The UITableView has a way to reuse table cells that aren't being displayed anymore. That way if you only display 6 cells on the screen at once it doesn't keep on creating more as you scroll, but reuses the cells that have gone off screen. whenever you want to create a new cell, first query the tableview to see if it has any to reuse and if not then create a new one.
an example of this can be found on slide 55 of the standford iphone course note found here: http://www.scribd.com/doc/7671058/Standford-CS-193P-11Performance
According to Apple, you should not use autorelease and instead should retain and release objects explicitly as needed. autorelease will not release an object as soon as its function is over. If in the tableview you are using images downloaded from a webservice, try and cache these images and reuse them if possible. Another option is to only get those images which are being displayed.