I have gone over a silly amount of forum posts and questions here. while i would love to take this advice: http://www.cocos2d-iphone.org/forum/topic/2003 I suppose i just don't trust 'them' as much as this community.
so, I ask, is this a 'negligible leak' if it only seems to happen once when i push a view onto the root view controller?
The core audio libraries have always given me unfixable memory leaks. Just ignore them because they are Apple's fault.
There's 416 bytes leaked there but if it only happens once then it's nothing to worry about.
With my code, the AVAudioPlayer class leaks each time I call the play method. It's rubbish. Luckily it's only a small leak.
Related
this a question I always wanted to ask.
When I am running an iOS application in Profiler looking for allocation issues, I found out that NSManagedObject stays in memory long after they have been used and displayed, and the UIViewController who recall has been deallocated. Of course when the UIViewController is allocated again, the number is not increasing, suggesting that there's no leak, and there's some kind of object reuse by CoreData.
If I have a MyManagedObject class which has been given 'mobjc' as name, then in profiler I can see an increasing number of:
MyManagedObject_mobjc_
the number may vary, and for small amount of data, for example 100 objects in sqllite, it grows to that limit and stays there.
But it also seems that sometimes during the application lifecycle the objects are deallocated, so I suppose that CoreData itself is doing some kind of memory optimizations.
It also seems that not the whole object is retained, but rather the 'fault' of it (please forgive my english :-) ) because of the small live byte size.
Even tough a lot of fault objects would also occupy memory.
But at this point I would like some confirmation:
is CoreData really managing and optimizing object in memory ?
is there anything I can do for helping my application to retain less object as possible ?
related to the point above, do I really need to take care of this issue or not ?
do you have some link, possibly by Apple, where this specific subject is explained ?
maybe it is relevant, the app I used for testing rely on ARC and iOS 5.1.
thanks
In this SO topic, Core Data Memory Management, you can find the info you are looking for.
This, instead, is the link to Apple doc on Core Data Memory Managament.
Few tips here.
First, when you deal with Core Data you deal with an object graph. To reduce memory consumption (to prune your graph) you can do a reset on the context you are using or turn objects into fauts passing NO to refreshObject:(NSManagedObject *)object mergeChanges:(BOOL)flag method. If you pass NO to that method, you can lose unsaved changes, so pay attention to it.
Furthermore, don't use Undo Management if you don't need it. It increases memory use (by default in iOS, no undo manager is created).
Hope that helps.
I'm really pulling my hair out on this one, it seems that I'm having severe issues with memory management on an iOS app.
Here's the case: first I load table. When the user taps a cell, it presents a complicated view. The most memory consuming about the view is that it's loading 20+ UIImages of 500x500. There are two other tabs in that view, loading a list of media (those UIImages, but then in a table) and another simple table.
When I return back to the first table view, apparently over 250 kB is still allocated on heap. I know the view is complicated, but there's no reason to keep so much memory alive. And well, guess what, when I do switch to the view a lot, eventually the app runs out of memory and gets killed.
What I tried to solve it:
Fix all Analyze issues, so according to that there are no leaks anymore.
Check all inits again for releasing, making use of autorelease where possible.
Checking all the memory leaks using Instruments -> Leaks. In a runtime of 6, I get not more than 2 or 3 leaks.
Last, Instruments -> Allocation, checking the heap. This is what bothers me, between two marked heapshots I get a difference of 250+ kB. I've looked into it, using the detailed views. I can't get my head around it: when it's pointing to one of my methods/classes, I'm pretty sure everything in there is either released or autoreleased. It's also pointing to a lot of not-mine (say QuartzCore) methods/classes.
Also, I don't understand why autorelease is not autoreleasing. I mean, it sometimes looks like an object that is marked for autoreleasing, is released way too late. I haven't created any NSAutoreleasePools myself, so is it possible that the pool is drained only when the runtime stops? How can I periodically drain the pool (even if it's not mine).
Any help is greatly appreciated.
Kind regards,
Reinder
Used this for the heap checking: http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/
Are you using imageNamed to load your images - this method will keep all images cached in memory. Try initWithContentsOfFile instead.
Watch out though; initWithContentsOfFile: won't cache at all so if you use this method a lot for the same image then you should be using imageNamed:!
I think you might want to try to optimize your design first and read guides for efficent memory management. A better understaning of the components and the runtime helps more than tracking memory allocations and will make it easier to find the leaks.
First you should always use release. Only use autorelease when necessary.
Make sure you follow the guidelines for UITableView implementations and efficient management of UITableViewCells (lazy loading, cell reusing etc.).
Check if you have retain-cycles (retained view controllers won't be deallocated).
Track the deallocation of your view controllers and objects
Don't keep stuff in memory you don't need anymore.
Don't load stuff you don't need right now.
So I've gotten to the nitty gritty part of my app development where I am going through checking for lingering memory leaks. I decided to give Xcode's Leaks a whirl. When I first ran it, it was telling me that I had no memory leaks. After a minute of rejoicing, I took a closer look, viewed the allocations and realized that I had several objects floating around in memory that I didnt want there. For instance, every time I created a UIAlertView (which was quite often in my app), I never release'd them when they were dismissed from the view. This led to having several UIAlertView objects floating around.
So, my question is: How does Leaks detect a memory leak? Why didn't tell me that there were any leaks when I had UIAlertView objects floating around? Am I just using Leaks wrong?
If you still have pointers to those UIAlertView instances, they aren't technically a leak yet. Only when your app can't get to them anymore it is considered a leak by the Leaks instruments. As you noticed, there are indeed ways to have stuff still around that you would expect to be gone. That's where the Allocations instrument comes in handy.
I am an experienced C/C++ programmer, and familiar with memory management issues. I've also shipped a couple small iPhone apps in the past. I am attempting to check my latest app for memory leaks, and I can't make any headway, because there are so many of them. Just starting the app and viewing the first screen shows over 12,000 leaks.
I know I've probably overlooked various things, but I was reasonably cautious in writing the code. I made attempts to release everything I alloc'ed in my dealloc method. It is like my app delegate never gets released, because I can see a couple things that are only alloc'ed once, in the app delegate's init method. They are never modified, and are released in the dealloc method.
This app is built around a tab controller, with around 15 views mainly set up using Interface Builder.
Any help would be appreciated.
Instruments of apple is pretty advanced.. it can show you the exact method that originally created the memory leak, I suggest taking a look at those methods and carefully reading your code ,there usually is this line of code in there and you thought OMG how could I be that stupid.
If that doesn't help, try to "Analyze" with xcode, its pretty good at finding errors and leaks in your code and saved my * a couple of times.
Every thing works fine in my app up until I detach a thread to read audio data out of a file and process it.
Garbage Collection seems to not know anything about what happens on this thread no matter what I do. I've tried [NSThread self], [NSThread currentThread], [[NSGarbageCollector defaultCollector]collectIfNeeded] and collectExhaustivly].
I switched to NSOperation with NSOperationQueue from NSThread.
None of these suggested solutions have worked. Most recently, I switched from NSMutableArrays to
Float32* pfArray= calloc(numFloats, sizeof(Float32));
to hold my data, and used
free(pfArray);
to free that memory. This is working better, but still leaking a decent amount.
Garbage Collection does seem to start working to some extent after the "real mem" indicated in Activity Monitor hits some arbitrary number, but when it does appear to be working, it does NOT free all the memory being used. It just doesn't let it go much higher than the arbitrary threshold.
I've read that GC is the way to go, but now I'm unsure and have an almost fully written program. Any suggestions would be very helpful. Thank you!
Garbage collection indeed works on all threads of the app. You might have unwittingly kept a reference to some object rooted, thus leaking a subgraph; without the original code, however, not much can be said.
“collectIfNeeded” implies that it will not collect if collection isn't needed.
Use Instruments's Heapshot feature (part of the Allocations instrument) to find out what objects are remaining alive, and its Object Graph instrument to find out what is still holding on to the objects that you think should no longer be needed.