I am having trouble with using up a lot of memory at the moment and i am doing everything i can to shave off and optimize my code where memory is concerned... Currently my game has most of it's Nib files load all of its variables in ViewDidLoad, Now my question is that in my viewDidUnload that i should not only nil everything in viewdidunload but i should also release it? Even if it is not an IBoutlet?
Also if i release and nil it IBoutlet or NSMutablearray..whatever should i also release it in dealloc?
Release your instance variables on dealloc and set your properties variables to nil on viewDidUnload.
Also, why dont you enable ARC (Automatic Reference Counting) for your project on Xcode.
If you are new to memory management on Objective-C I'll highly recommend you to take advantage of this functionality. Is better than a garbage collector, it automatically detects when an object is not longer needed and release it.
Related
Im experiencing memory leak on static menu scene, it appears that it happens on every scene, game scene itself but also static menu/gameover. Memory appears to be deallocated correctly (and it's reduced when scene is gone).
Those static scenes does not conatins even update callback defined.
It's all setup in didMoveToView and inside it there are couple SKLabelNodes and SKSpriteNode allocated with spriteNodeWithImage.
I have tried to use dealloc to monitor if scene got's deallocated correctly, and it appears to be so it seems it's not the source of the issue.
Browsing google pointed me to some other threads created on stackoverflow that
spriteNodeWithImage
textureWithImage
May cause
-Memory leaks
-weird error "CUICatalog: Invalid Request: requesting subtype without specifying idiom"
So i have tried to create UIImage imageNamed and then put in into texture and use in SKTexture, actually it has removed CUICatalog error (which anyway, seems like a stupid message which did not been removed by apple - can anyone confirm that ?)
But according to memory leaks this didn't help at all, and anyway anything in that scene is being created once on beginning so i have no idea why this memory keeps growing and growing like 0,5mb per sec.
Looking forward for any tips.
Best regards
Actually i have found the source of the problem.
It seems debugging physics makes huge memory leak
skView.showsPhysics = YES;
It's not a big problem since it happens while debugging only when showsPhysics=YES.
But good to know anyway.
I'm currently investigating what appears to be a large memory leak in my application. Using Instruments' Allocations template and the mark generation feature I can see that after a UIViewController that I present is released there is a growth of 35MB!
I know the UIViewControlller is released because I have a log message that is printed when dealloc is called.
One thing that really stands out in the report is the "VM: Allocation" item which shows 16MB of memory allocated. I have no idea what this is, also it's just two allocations using 8MB each, this seem incredibly high.
My UIViewController has a MKMapView, UITableView, various labels and a slideshow of UIImages.
The UIViewController is using a nib file and IBOutlets which are mostly all weak references, there are a few strong IBOutlet references where I add and remove view's at runtime that I need to keep a strong reference to. Though it's my understanding that these will be released by ARC anyway, just to be double sure I nil them out in dealloc.
Viewing the stack trace for the two VM: Allocations shows only internal calls and nothing that is related to my code. It says the responsible libraries are libGLVMPlugin.dylib and libCoreVMClient.dylib.
Interestingly if I remove my MKMapView from the nib file the growth shows after the UIViewController is released goes down dramatically.
Can anyone shed some light on this or give me any pointers?
I know this question asked many times, but I have not yet found solution. My app goes between views in this order a->b->c->d->b. This means that from view "d" I don't always go back, and the needs to jump to view "b". The problem is that memory of views "c" and "d" is not release and after some loops (b->c->d->b->c....) the app crashes. It is very important the order of the operations. I have to mention that I navigate between views with modal segue. I have tried releasing memory in many ways:
Putting in DidRecieveMemoryWarning: _myProperty = nil;
Putting in ViewDidUnload: _myProperty = nil;
Changing all properties to weak.
Wrapping code with #autoreleasepool.
Nothing helped, the app crashes after awhile, how can release views and memory by "force"?
ARC was made for not releasing by force letting the OS handle all releases. You should use xcode instruments to find out how much memory your app is using. It sounds to me like you bloat your memory so it will be best for you to check how much memory is being used and what can you do to optimize it so allocation capacities will stay in an acceptable limits. (e.g. Loading 1000 images in a view where each image is 1Mb in size is a total waste and will probably cause such crash. This example is intentionally exaggerated so you'll get the idea)
Objective-C (primarily) uses a reference counting memory model. There's manual reference counting and Automatic Reference Counting (ARC).
How ARC Works
If you've ever worked with manual reference counting and run the clang static analyzer tool, you'll see that it does an amazing job of finding memory leaks. This is the idea behind ARC - if the analyzer can do such a good job of finding leaks, then why not let it perform memory management?
So, the analysis is done at compile time, and the resultant code is instrumented with retain and release calls. This is the foundation of ARC and its a great memory model, giving a good balance between performance and ease of use. Its especially useful in mobile computing, because, unlike garbage collection it won't require any additional CPU cycles or battery drain.
(NB: ARC also introduces weak references, which is a way of nulling out dangling pointers at runtime).
Using ARC is not quite as simple as garbage collection - you still need to know how the reference counting memory model works. The following problems can occur.
Retain Cycles
The main cause of a memory leak is a retain cycle. This is where object A has a reference to Object B, and Object B has a reference to Object A. For example an AirlineFlight contains a Passenger and the Passenger has an AirlineFlight -> memory leak.
This is very common in Cocoa. Another example is a ViewController owns a view, and the View has a delegate, which is the ViewController. Sound familiar?
To avoid the retain cycle, its necessary for one of the objects to not retain the other. The most common approach is to designate one as the parent, and the other as the child. The parent retains the child, but the child does not retain the parent. Example:
View Controller
#interface MyViewController
#property (nonatomic, strong) MyView* view
#end
View
#interface MyView
#property (nonatomic, assign) MyViewController* controller
#end
The retain-cycle is now broken and the memory leak will no longer occur.
Dangling Pointers
The above example no longer has a memory leak, but can lead to another problem - dangling pointers. The view controller might go away, while the view still has a reference to the controller. Any call to the controller will now cause a crash.
There's two ways to fix this:
Nil out the reference to the controller in the dealloc method. . . but probably just
Use a weak reference, as follows:
#property (nonatomic, weak) MyViewController* controller
iOS 5 and above (or OSX 10.7) have a little runtime utility that keeps track of dangling pointers and nils them out for you - these are called weak references.
Finding memory Leaks
There are several ways.
Use the clang static analyzer to detect retain cycles.
Use the Instruments tool
I like to put log statements in the dealloc method of my controllers and other key classes to ensure they being released.
Finding Dangling Pointers
Compile with the environment variable NS_ZOMBIES_ENABLED (or edit the Scheme in Xcode and click the checkbox, which will set this parameter for you).
Auto-release Pools
Another problem that can occur is too many objects being allocated within a run-loop. . To correct this you can create another auto release pool, within the main pool.
#autoreleasepool
{
}
(In your case, I don't think this is the problem).
I'v also come across this problem, but I was writing a cocoa app for OSX10.8, not iOS.
I found that the app memory usage will increase all the time when I do something like showing a new window then closing again and again. It seems like the window I see is a new one every time. 10MB->20MB->30MB...
Finally, I directly double-clicked the .app file, and checked the activity monitor again. The fact was that it really came to be normal. The app ran in release mode is the same situation. So I suppose ARC will not release memory immediately in debug mode if you run a app via Xcode Run.
Are you using heavy png images? I had this same problem a while ago and a height x width image uses height x width x 4 of RAM (since it is shared with GPU). Only my background wasted 120MB approx. If it is the case try to redimension your images.
i'm currently working on an ios project with some people, one of us decided to use ARC in a part of the app.
Unfotunatly, we are currently experiencing some crashes when coming back from background.
Here are the steps we follow to crash the application, we perform them with the ios-simulator:
start the application
get on a ViewController A (coded with ARC)
get on a ViewController B (not coded with ARC -to be honest i don't
know if it's relevant-)
put the application in background.
simulate a memory warning (thx to the simulator)
start again the application, we'll be on the ViewController B
go back on the Viewcontroller A
the application crashes pointing the main function with an
EXC_BAD_ACCESS
We did try to use NSZombieEnabled to YES, but when we do it, the application doesn't crash and keeps running perfectly, so we wonder if it might be possible that NSZombieEnabled doesn't work well with ARC?
if anyone could give me a quick and clear insight about ARC and NSZombieEnabled that would be apreciated, i think i know how all of it works, but apparently i must be missing something.
Thanks anyway for your help and time.
Better than using the NSZombieEnabled, you should Profile the project, and use the Zombie instrument. When you do the same thing it should stop and say "zombie messaged", where you can click an arrow to see the class that is a zombie, and where it was allocated/deallocated.
I don't think the crash has to do with ARC, instead in viewDidUnload you are deallocating something, and then not setting a reference to nil - when you come back it tries to use the invalid reference.
Probably you would be better off if everything used ARC as it really helps to cure issues like this (the bug is very likely in the non-ARC code).
I have a question about ARC nad NSMutableArray.
Here's the case:
I have a ListView with a NSMUtableArray (arr1) that contains all the elements of the listview. A separate thread, which runs in native code, makes callbacks into objective-c ListView. The native code creates a new NSMutableArray (arr2), fills it with elements of my custom class (each element has a name, id, icon etc), then passes it onto the ListView.
In the ListView, first I clear the array with [arr1 removeAllObjects], then I add each element from arr2 to arr1 with [arr1 addObject: ..].
NOTES:
*All the code, both native and objective-c, is compiled as Objective-C++ code.
*The native code part that allocs and init's arr2 (and all its elements) and calls the ListView stuff is all under #autoreleasepool directive
My questions;
Is there any memory leaks from native code?
Is there any memory leaks from ListView code? Will the old elements I release with [arr1 removeAllObjects] cause memory leaks?
Does #autoreleasepool provide the same functionality as ARC, meaning I wont have to explicitly release the objects?
1) There shouldn't be, but sometimes there are small leaks (I've seen some with the keychain, and some audio libraries). It isn't your problem for dealing with and in most cases would be impossible to resolve.
2) removeAllObjects does send release to all the objects in the array. You can see this by putting a break point in the dealloc method.
3) yes ARC #autoreleasepool works the same
The situation you've described above looks safe to me.
Is there any memory leaks from native code?
Not due to lack of release/autorelease (you should look at weak/strong properties, discussion here)
Is there any memory leaks from ListView code? Will the old elements I
release with [arr1 removeAllObjects] cause memory leaks?
No.
Does #autoreleasepool provide the same functionality as ARC, meaning I
wont have to explicitly release the objects?
You CANNOT release objects with ARC. The autoreleasepool will just ensure that the objects that were allocated within it are destroyed after the closing curly bracket (useful if you have a for loop that allocates tons of stuff on each pass and you want to ensure that everything is cleaned up between each of them, for example).