Did you ever consider yourself as a plumber while testing any application? Well, you sort of are one if we are talking memory leaks as you are the one locating and solving such issues. But don’t hurry to the nearby store for some blue pants with suspenders and a red hat with a big ‘M’ letter. You don’t also need to become Italian and to grow a moustache as, I believe, you have all you need at your office place for the kind of plumbing we will be talking about.
What are memory leaks?
Allocated memory blocks that are no longer referenced by the program may be considered memory leaks. What’s so bad about them? Memory leaks are wasting space as they are filling it with lots of inaccessible data. They are also time-wasters as they are the cause of extra paging activity.
How are memory leaks dangerous?
If there is some memory leaking it will, within some time, make the system to assign some extra virtual pages to the leaking app. If we are talking of a malloc using app then memory leaks are but nasty bugs and are to be fixed. If your application will be using Objective–C objects only then you are more or less safe as the ARC of your compiler will avoid this issue via object deallocation. But, if your application will be mixing both Objective–C objects as well as C0based structures you will have to pay extra attention to object ownership management.
Where to find them?
For instance you are to be aware that any malloc library is only capable of reclaiming memory you have told it to reclaim. In order of proper balance maintaining you are to call malloc or (if necessary) any other allocating routine with a nice corresponding free. Memory leaks are often occurring after somebody has forgotten to dellocate memory to an embedded pointer is the structure of data. If you wish to assign memory for some of your code’s embedded pointers, then be sure not to forget to release that particular memory for that particular pointer. There is one more mistake that may be considered quite typical.
A memory leak will take place if you will be assigning memory to a pointer. (The following happens within some kind of a bluer or I don’t even know what hence such a mistake happens extremely often and nobody seems to remember of it). After those operations you are assigning the pointer with a different value without previously releasing the very first memory block. If that is your case you are to overwrite the address from the pointer thus erasing references to previous blocks. Not so hard, is it? Sure, these are far from all possible memory leakage scenarios yet these two are the most common ones.
Several Pro tips that will assist you greatly
The following several pieces of advises are working great only when combined with the leaks tool, nevertheless there are still tips great for MallocDebug or even general use regardless whether it’s iPhone application testing or Mac desktop app testing.
- If we are talking iPhone Cocoa apps and you are facing a leak the odds are that your code is desperately going for using any object that is already freed or the memory buffer. Setting the NSZombieEnabled variable to YES will assist you with finding messages of objects that are already freed.
- If you are looking for hardcore malloc debugging library assistance run your app against dylib in the gdb.
- For better results you are to run leaks while unit testing.
- If you have functions with memory leaks that are already known you may use –exclude on leaks to filter them.