I checked my application's memory leaking problem and these memory leaks are found.
How can I solve these memory leak?
I used Leaks tool in Instruments. Here are the screenshots
Screenshot 1
Screenshot 2
Switch to the Call Tree, select the options indicated in screenshot, then double click the code line.
I have a Viewcontroller which contains wkwebview when I pop it from the navigation controller I get memory leak
The stack trace leads WkWebview instantiation
I am not using any delegates as well.
I am really wondering what causes this and how to fix this
It is not observed for a long time (at least I can't remember when I met it last time). Just tested in Xcode 11.2 / iOS 13.2. No leaks - neither in simple test project nor in Playground.
Thus, I assume it should be analysed real usage, which introduces leak.
I'm making a Swift 2.2 app in XCode7.3 using SpriteKit & GameCentre.
My issue is the memory used by the app continues to grow (an additional ~20MB is grabbed every second or so). Eventually this causes the app to crash due to memory issues. I get similar results running on a device (iPhone 6s) & simulator.
I've had a go at running it through Instruments (screenshot below) and this seems to show the issue.
Instruments screenshot
From digging into the instruments output, it seems to show a memory leak occurring off a 460 KiB malloc call. I haven't manage to isolate what's causing this from the stack trace.
Instruments output available - not certain how to attach it here. Any suggestions / pointers on where to start?
Try binary searching your code. Comment out half your calls. Still getting a memory leak? Ok, now you've reduced your search scope by half. Comment out half of the remainder. No memory leak? Great, you've just narrowed down your problem to 1 quarter of your code. Once you start getting the specific code that is causing the leak, you'll get much more useful answers out of StackOverflow.
Answer has been found - cause is a bug in the Apple/Spritekit code.
As part of setting up the scene I was setting showFields of the SKView to true. Once I disable this (false) the memory leak issue goes away.
From searching for this I found - https://forums.developer.apple.com/thread/27870
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 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.