running my app through Instruments "Leaks" it's saying I've got a leak which seems to happen with this code -
-(void)podAppears {
podCount ++;
NSString *podName = [NSString stringWithFormat:#"Pod%i",podCount];
Pod *thePod = [[Pod alloc] initWithOwner:self withName:podName];
[pods setObject:thePod forKey:podName];
[thePod release];
}
I can't see anything wrong, but I'm fairly new to Objective-C & memory management in general. Any help much appreciated!
That code looks fine. When Instruments informs you of a leak, it tells you where the leaked object originated. It's likely that the actual leaking of that object is occurring elsewhere in your app. You should look at other locations where you access your Pod objects.
Related
I'm just investigating some memory leaks in my app, I'm using Xcode 4.0.2. I've run the Analyze tool in Xcode and a good few memory leaks have been identified. I'm relatively new to Objective-C, this is my first app. I've pasted the code here:
http://pastie.org/3155043
I've added comments to the above code, where the memory leaks are occuring.
Memory Leak One: Method returns an Objective-C object with a +1 retain count (owning reference).
Memory Leak Two: Object allocated on line 248 and stored in 'imagesNames' is not referenced later in this execution path and has a retain count of +1 (object leaked).
Memory Leak Three: Potential leak of an object allocated on line 246 and stored into 'cmpWordoutStr'.
Any help appreciated.
Regards,
Stephen
You might want to consider using Automatic Reference Counting in your project.
I asked a question the other day on here, as I wasn't sure that it was a good idea, but the answers convinced me that it really is a step forward and is well worth taking advantage of:
To ARC or not to ARC? What are the pros and cons?
Hope this helps :)
Leak 1) You don't show the return or identify which variable is returned, so not possible to definitively diagnose this one.
Leak 2) You alloc/init an NSString and assign it to a variable that is never released. This is wrong for two reasons:
For each alloc there must be a corresponding release somewhere.
There is no point in doing alloc/init on an empty string. If you want an empty string just use #"".
Leak 3) Basically the same as (2).
(You really need to get a good book on Objective-C programming and study and restudy the section on storage management. Otherwise you'll be stumbling around in the dark.)
You're allocating an object first
NSString *cmpWorkoutStr = [[NSString alloc] init];
and then reassign the pointer without freeing the memory:
cmpWorkoutStr = [cmpWorkoutStr stringByAppendingString:indWorkoutStr];
hence the leak.
I didn't analyze your code in depth, but I guess you actually want NSMutableString there.
As Tom Andersen suggested above I used auto release and this solved the problem, example below:
NSString *cmpWorkoutStr = [[[NSString alloc] init] autorelease];
NSString *imageNames = [[[NSString alloc] init] autorelease];
Regards,
Stephen
I am getting a memory leak in my objective-C code that I don't understand. I have this code in a method that gets called several times:
AnalyzeBpm *analyzer = [[AnalyzeBpm alloc] init];
while( sample != NULL)
{
//do something with analyzer
}
[analyzer release];
When I run this code through Instruments, I get a leak everytime I allocate Analyze Bpm(which is a couple of hundred times). I looked at my AnalyzeBpm class, and everything I allocate in that class gets freed or deallocated. So why is this code creating a memory leak?
When Instruments identifies a leak, it is showing you the line of code that is allocating the leak, not the line of code that causes the leak.
Somewhere something is retaining analyzer without releasing it. You need to find that unbalanced retain. It may or may not be in the AnalyzeBpm class.
Your alloc-init and release are balanced, so it has to be something else — something in your while loop.
I've been working on the leaks in my program today and I understand most of them but this one is throwing me for a loop:
[startAndEndPoints addObject:[NSNumber numberWithInt:buttonTag]];
The Leaks instrument is pointing to this saying that it is 100% of a leak. Can anyone advise?
startAndEndPoints is a NSMutableArray.
Did you compare your situation to iphone app NSNumber memory leak ? Leaks is telling you how the leaked object got created, not where the leak is. You're probably handing this NSNumber object off to someone else later, and that someone else is over-retaining it.
I'm following the Stanford iOS development lectures and I have a Calculator brain class which has been alloc init in a controller but I haven't released it in the dealloc.
- (CalculatorBrain *)brain
{
if (!brain)
brain = [[CalculatorBrain alloc] init];
return brain;
}
I ran from XCode -> Run with Performance Tool and the app started and no leaks appeared, I then clicked the home button in the iOS Simulator and nothing, I then double clicked the home button and closed the app and still nothing.
I also did Build & Analyse and it didnt spot anything
Could you let me know why its not picking it up?
It appears as if there is no detectable leak. Look at this line:
brain = [[CalculatorBrain alloc] init];
As long as brain points to an object, that object won't be considered a "memory leak". If at some point you do this,
brain = nil;
Then the leak will register. Deallocating the container object will also achieve this, but are you sure it's being deallocated? (It won't be deallocated when your program exits, for example.)
The problem: Leak detectors cannot detect all memory leaks -- this is a mathematically proven fact. Most detectors only detect unreachable objects, and many leak detectors are especially susceptible to false negatives -- in C it is hard to tell the difference at runtime between a pointer and an integer.
Edit: It sounds like your application only ever creates one instance of the controller, which only creates one instance of CalculatorBrain. If you think about what a memory leak really is, you can define it as unused memory that your program does not release back to the operating system.
While the program is running, CalculatorBrain is always in use and therefore it is not a leak.
When the program exits, the operating system automatically reclaims all memory used by your process, therefore there cannot be any memory leaks after a program exits.
If you want to create a leak to see what it looks like, you could create a new CalculatorBrain multiple times while your program is running, but forget to release the unused versions. In this scenario, as your program runs, more and more instances of CalculatorBrain would accumulate. On iOS and other embedded systems, this will generally crash your program. On a modern 64 bit computer it will gradually fill up the available swap space until you run out of swap, address space, or some other resource -- causing the program to crash or making the system very unresponsive.
Standard practice is to not care about deallocating objects which are supposed to exist for the entire program's run.
The analyzer cannot find all memory leaks. As far as it is concerned, storing the instance into the ivar doesn't leak it from that method, and then in dealloc it doesn't realize that the ivar should be released. XCode 4 may have improved in this respect, I don't recall (I still use XCode 3 myself).
As for the performance tool, remember that an object won't be considered leaked until nothing holds a reference to it anymore. So even though your controller doesn't deallocate the brain, the brain won't be considered leaked until the controller is deallocated (or receives a brain transplant). Also, note that on *nix-like systems, memory allocations are automatically cleaned up on process exit. So it isn't really a leak if you allocate memory for objects that should exist for the lifetime of your process (e.g. the app delegate and anything it permanently holds on to) and rely on this behavior to free it on process exit.
Well... it's true that leaks can't detect all memory leaks, but let's say that you are doing this:
myIvarBrain=[self brain];
If you are giving it to an iVar (released in the dealloc of your class, and without accessors), actually there is no leak at all. The returned RC is one and it will be one since the deallocation of your class. If you don't release it in the dealloc, you should wait a dealloc of your class to see a memory leak.
Does make sense?
I am working on mounting some network shares in a program. The URL and username are saved in a dictionary with the password coming in from the keychain which is changed to a NSString, used and released. I have traced the only memory leak to the actual mounting of the server:
error = FSMountServerVolumeSync((CFURLRef) [objects objectForKey:#"url"], NULL, (CFStringRef) [objects objectForKey:#"username"],(CFStringRef) password, NULL, 0);
The object for "url" is a NSURL and the username is a NSString.
In the leak performance tool it says:
Leaked Object: NSCFString responsable library: smb, responsable frame: smb_url_to_dictionary
If I look at the history it is a CFString malloc for 32 bytes and then goes through 8 iterations of CFRetain-CFRelease from smb and NetFS libraries which results in a +1 retain count.
Being new to Objective-C and memory management I thought I was doing everything correct I have released everything alloc'd and really not sure how this leak is occurring.
Is there something with the FSMountServerVolumeSync that is tricky thats causing this leak?
Is there any way to look during runtime at the memory location to determine what is there to see what the leak is from?
Also what does the NSCF stand for?
Thanks for the help