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?
Related
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.
I'm testing my app on Instruments -> Leaks
And I have a leak that I can't eliminate, because I can't understand its roots.
What should I do?
P.S. These leaks appear after such steps:
App goes to background with visible keyboard.
App goes to foreground.
I enter any letter on the keyboard.
If the keyboard is invisible before going to background = no leaks
one http://iwheelbuy.com/leak.png
two http://iwheelbuy.com/leak1.png
three http://iwheelbuy.com/leak2.png
I will suggest in applicationWillEnterBackground in AppDelegate.h, just resign First responder.
I'm getting strange memory allocations from core iOS libraries, seen in Instruments Allocations (Malloc 1.00KB) which continually rise and result in app crash (iPad).
The app allows the user to browse through articles (body in webview, title/author/date in labels) - the problem occurring as each new view controller is loaded (previous view controllers are released/deallocating - this isn't the problem).
The following CoreGraphics allocations only happen when the .text property is set for the UILabel:
CoreGraphics "CGGLyphBitmapCreate", "CGFontSetStrikeValue" - sometimes one or both of these shows 6 or 7 times (1KB each) but at least one of each every time view loads.
In addition to this, Foundation "[NSNotificationCenter addObserver:selector:name:object:]" sometimes appears, sometimes not, sometimes up to 6/7 times on one load. I understand why adding observes this might allocate some memory, but surely deallocating view controller with "[NSNotificationCenter removeObserver:self] should remove all references again.
I've included screenshots from Instruments... won't even address the WebCore and libcache.dylib allocations that **sometimes show up on load. Very confused here too.
Did you track leaks? As long as it doesn't leak memory you normally don't have to worry.
Maybe you have a thread without an autorelease pool set up? If this is the case, and an autorelease object is created, e.g. by a getter method, the object cannot be retained by an autorelease pool since it does not exist, and it will leak.
So it your app is multithreaded, make sure that every thread has an #autoreleasepool{} block that covers most of the thread code.
I'm using a lot of small images that are placed into UIImageView objects. Currently, I'm trying to foresee the problems that might occur later, such as memory warnings, staying in background and etc. My app is quite small - less than 10Mb but still, I'm a little bit concerned. The reason is that I'm not sure how my app will cope with the situation when a lot of UIImageViews are loaded on screen, then app goes to background, and then after a long time comes back. Do I have to reload all on-screen UIImageViews?
I have read that iOS will cope with UIKit data (such as image views) itself when backgrounded. And that I do not need to worry about restoring this though. It would be OK if my UIImageView objects would use PNG image files directly from app directory. But the thing is I'm using spritesheets (files with several images packed inside), then pulling those images with CGImageCreateWithImageInRect, and then passing to UIImageView at some time point. Now, I'm questioning myself, will iOS cache my on-screen UIImageView objects, or do I have manually to reload those UIImageViews when app goes active? I understand that if a lot of apps will be running in background then my backgrounded app might be killed. But I'm worried about the situation when my app will be still alive (in background) but with released UIImageView objects...Please share you knowledge and insights :)
Current implementation of "background" apps do a complete snapshot of your app memory. Such approach guarantees that app will be restored after complete killing from a memory in unchanged state. This mean that you do not need to do any additional manipulations such as persisting of code-generated images etc to support restoring of the app. UIImageView will not be unloaded automagically if you will not implement a clean-up logic inside of applicationDidReceiveMemoryWarning for UIApplicationDelegate instance. However an auto clean-up logic implemented for cached UIImages loaded thru imageNamed method.
i've a navigation controller with several viewController and tableViewController.
I'm using all autorelease objects, the problem is that when i push a new view and i use it, memory from Instrumets increase of a bigger value of memory released when i come back in the navigationController. There's not leak warning, when i return to the view then, memory will not increase again, it's like if was all in cache.
I've tried also using objects own by me, with alloc....and release but the story is the same. Is it normal?
UIViewControllers (or to be exact, views/resources/xibs associated with them) are interesting since iOS will hold on to the resources in memory and unload them as required. This is why often the dealloc method will seem like it's never called. However don't worry, if you did proper memory management, your controllers and resources will be freed up as required - if there's a low memory warning sent to your app, all the views that are hidden or have been popped, will be unloaded and dealloc'ed.
Try testing your app again, just like you did before, but this time emulate low memory usage (can be done in simulator from the Hardware menu), then see if memory usage drops due to your controllers being freed up by the system