After spending several hours on finding some leaking NSCFStrings in Instruments I seem to have realized that calling Cocoa's -animator proxy is causing this.
It is always reproducible: Just create a new Xcode project, add a new NSTableView in IB, fill it with some test data and run Instruments with Leaks. Once you hover over the NSTableView so that the scrollers fade in and out, you'll notice at least one leaking object in Instruments.
Although I've already filed a bug to Apple, can anyone confirm this leak?
Demo-Project: https://www.dropbox.com/s/lszveuwrsuaxxg5/TableViewMemoryLeakStackOverflow.zip
Screencast: https://www.dropbox.com/s/vqtwbkus3jygdb3/ProxyAnimatorMemoryLeak.mov
This bug was resolved in OS X 10.9.3.
Related
How can I track down abandoned memory if in Xcode Instruments don´t show my custom classes?
So I can see the heap is growing after I perform an action with my app (open a view and go back to the previous in my case) and I could fix some memory issues before by tracking down my mistakes in my code.
Now however, I only see things like in Generation N (= Heapshot N), non-object and I don´t know any more how I can fix the leaks. The responsible caller (not seen in the screenshots) also show no own classes/objects.
Edit
The Showing View is a UIWebView. I searched the web and found rumors that UIWebView doesnt properly releasing data. Could that be the issue? I can´t find any solution.
UIWebView is notorious for causing memory issues.
Make sure you set the UIWebView object's delegate property to nil if you assigned an object to it as documented in the class reference. You can do this in dealloc.
Cleanup the web view in viewWillDisappear:animated: by stopping URL loading with a call to stopLoading and/or setting the HTML string to nil by calling loadHTMLString:baseURL: to workaround any memory being held.
Good afternoon,
I was doing some Instruments testing on my iOS app that I'm about to release, but I noticed some VERY strange memory leaks, that appear to be coming from System libraries.
When I ran Instruments I got this leak:
Which is extremely weird from my point of view! I went to the Call Tree of these leaks and they all appear to be deep C++ system calls.
What confuses me even more is that this project has ARC enabled, and I ran it through the Analyzer and no problems showed up.
Even more weird is that this DOES NOT happen on the Simulator, nor on my real iPad, but on my iPhone this problem happens.
And when I check "Show Obj-C only" and "Hide System Libraries" the call trace disappears which leads me to believe my code is not responsible for the leak.
Why is this happening and what can I do to fix it?
Thanks guys.
The above leak is not a leak inside your app and it is inside apple's library which you dont have to worry about. If you have fixed all the leaks inside your app, you are fine. Apple will not reject your app just because of this small leak.
I am new to ios development. I am having a very serious issue now. My application is almost complete but it crashes very often due to memory warning. The memory warning is received whenever I present a new view controller on the top of the existing view controller. The custom view class adds UIWebView to its view when the new view controller is loaded.
I tried to debug the memory allocation with instruments but do not have any idea on how the memory is being allocated. The screenshot of the heapshot analysis shows bunch of non-objects as in the figure below and when I see the stack trace it points to adding the webview.
Please suggest me how I have to debug. What does these non-objects point to and how should I deal with them. I thank you for your suggestion and help in advance.
Non-object allocations are almost always used as backing stores within objects. I.e. an NSMutableArray will often be backed by several malloc()'d buffers that show up in non-object allocations in instruments.
Unless the non-objects are the only thing showing up as allocations in Instruments, you can ignore them.
Instead, focus on allocations of a specific type. Anything else in that Heapshot iteration? Looks like there is a CardScrollView in that backtrace on the right. Are they going away correctly?
I'm trying to solve a memory leak in my iOS app and struggling. I'm using the leaks tool to try to isolate the problem. To my surprise, the leak seems to be happening 100% within the UITableView gesture recognizer code. Specifically, the leak count increments each time I stop scrolling (release) the UITableView. Even weirder, this happens with a UIWebView as well. And with a UIScrollView.
So each time I release a drag action on any of these UIKit objects, I get a memory leak. The UI pieces are at different, distinct places around my app, so it's not just localized to one screen.
Ideas?
Not sure why, but making a simple [[NSOpenPanel openPanel] runModal]; creates a memory leak - seen in Leaks Instrument.
Seems off.
It's an auto-released object, shouldn't it be automatically released after ARpool is drained?
Is there a way to fix this?
NSOpenPanel is a singleton, which means you always get the same instance of the object every time you use it. This means that the first time you call [NSOpenPanel openPanel], an instance of NSOpenPanel is created and not released.
This is not a leak, it's an optimisation. However, sometimes the Leaks instrument picks up such once-only instantiations as leaks because the instances are (by design) never released.
NSOpenPanel is such a widely-used and tested class that any leaks in its standard implementation are unlikely to exist.
NSOpenPanel is not a singleton. It may have been at one time but looking at the latest NSOpenPanel.h file makes it explicitly clear it is not a singleton or at the very least Apple doesn't want you taking advantage of this implementation detail.
As for the leak, I was confused on when I should release my open panel and was retaining it. From the Using the Open and Save Panels section of the File System Programming Guide your life is a lot easier in 10.7 and above:
Important: In OS X 10.6 and earlier, you must retain an open panel prior to displaying it and release it when you are done with it. Because the openPanel method returns an autoreleased object, the panel is normally released shortly after it appears on screen. Retaining the panel prevents it from being deallocated and dismissed prematurely. You do not need to retain the panel if it is attached to a window and you do not need to retain the panel in OS X 10.7 and when using ARC.
Once I stopped retaining it things got easier and became a lot easier :)
Instruments is not perfect at detecting leaks - particularly for autoreleased objects, and has a tendency to have false positives. You might try creating a new NSAutoreleasePool, then draining it when you are finished with the NSOpenPanel to force release early - but I suspect you don't actually have a leak. If you are confident that the code looks good and it is autoreleased, then its probably fine.
I was seeing "leaks" reported in Xcode's memory graph tool when using NSOpenPanel in an unsandboxed app built on OS X 10.11.6 using the 10.12 SDK and Swift 3.0.1. The "leaks" were reported in PlugInKit classes (PKHostPlugin, PKDiscoveryDriver, etc.) and would show up even if the only line of code was let openPanel = NSOpenPanel().
NSOpenPanel's documentation states
In a sandboxed environment, Open panels are drawn in a separate
process by the powerbox, not by AppKit itself. When the user chooses a
file to open, macOS adds that file to the app’s sandbox.
After I sandboxed the application, the "leaks" did not show up in Xcode's memory graph as the NSOpenPanel implementation code was no longer in the application's address space, so I no longer had to worry about it.