How does a constant declared as below in the implementation part of a class is released:
static NSString *myconst = #"some data...";
Thx for helping,
Stephane
No, you don't need to release strings created with #"". You only need to release objects created with alloc, retain, copy or new.
You don't have to release it. The string literals reside in the executable's data section, not in the dynamically allocated memory (AKA heap).
There's no harm in accidentally calling release though. I'm pretty sure the literals are wired to quietly ignore that call.
retain, release and autorelease messages to strings of the above kind are ignored.
Read Apple's memory management docs here
However one thing to note here is passing release crashes the app. Hence the usual idea being, if you haven't used alloc or retain on the string, don't attempt to release it.
Also read this useful link here which explains the same thing.
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 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.
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.
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 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.