Memory leak on keyboard dismiss

Question

I have a view controller showing UITextField. Here I bring keyboard

- (void)viewDidAppear:(BOOL)animated
{
    [wordTextField becomeFirstResponder];
}

Then I have button which is dismissing the keyboard without closing controller itself:

- (void)cancel:(id)sender
{
    if([wordTextField isFirstResponder])
    {
        [wordTextField resignFirstResponder];
    }

}

After this Instruments will show me a leak on

#   Category    Event Type  Timestamp   RefCt   Address Size    Responsible Library Responsible Caller
0   Malloc 128 Bytes    Malloc  00:11.239   1   0x3b82550   128 UIKit   UIKeyboardInputManagerClassForInputMode

Somewhere in the stack [wordTextField resignFirstResponder] mentioned.

Even if I do not bring keyboard myself and let the user trigger it, I still have a leak. In this case there is nothing from my code mentioned in the stack.

Answer 1

The Leaks Instrument shows you memory that isn't going to be free'd in the normal course of the app (because there aren't any references to it). This in itself is no biggie, it will be free'd when the app exits. A lot of the framework code will allocate and leave these very small chunks of memory allocated. I have no idea if they are mistakes or essential to how the app runs. Whatever, we must accept that they are completely normal.

Leaks will identify these chunks of memory as 'Leaks' and that sounds bad, but this is not really the 'Leaks' that the instrument is there to help you identify.

The 'real' leaks are in the code that can be run many times and which allocate some memory that is never freed, so over time will consume more and more memory until all memory is used and your app will crash.

So if you have an app that no matter how long you use it for or no matter how you use it, it 'leaks' 128 bytes in an apple framework you generally don't have to worry.

However, if you have an app that say, every time you click a button it allocates a new string which is never released - no matter how many bytes the string is - if the user pressed the button enough times this would consume all the memory available to app and eventually crash it. This is the kind of leak you need to watch out for.

The leaks instrument realistically can't tell the difference between the two kinds, but you need to be able to. You might want a kind of singleton object, for example, that there is only ever one instance of, and that needs to exist for the entire lifetime of your app. You create the object on app startup and realistically you never need to free this object, it can be killed when the app exits. Leaks will flag it as a leak, and some other developers that you work with who assume that this means you don't know what you are doing will run to your boss like a little child and say "He's writing really leaky code, and that's reeeeally bad". And your boss, who isn't a programmer will take him seriously because it does sound bad and anyway he scraped a 2.2 in CS from a reputable University so he must know what he's talking about. When really it is completely reasonable and exactly what you meant to do.

So, use the Leaks instrument to find bugs in your code that will ruin your app. Don't worry about every byte found 'Leaking' in an Apple framework.