There are very common cases where objects may be leaking (not being deallocated when you expect them to) and instruments fails to detect this. One particular example is due to retain cycles using blocks, and it's very tricky sometimes to realize that some object isn't being deallocated.
MSLeakHunter provides a generic interface to construct "leak hunter" objects, that are in charge of monitoring the allocation and deallocation of objects of a particular class. In this repo, two particular implementations are provided: MSViewControllerLeakHunter and MSViewLeakHunter (for UIViewController and UIView instances respectively).
However, you can create as many leak hunters as you wish. The only thing they need is that the object they're expecting to be deallocated to have some method that gets called before this deallocation is supposed to happen.
For example, UIViewController will get a -viewDidDisappear: call some time before its deallocation. What MSLeakHunter allows you to do, is to keep track of that object, and in case -dealloc isn't called some time after that, it's considered pottentially leaked and it's logged in the console.
The implementation is pretty cheap, so it shouldn't hurt the performance of any application, but it's advised to keep this code disabled (through the MSLeakHunter_ENABLED macro) when shipping an app.
For more instructions on how to create other leak hunter objects, refer to the MSLeakHunter+Private header and to the included sample implementations.
- Add
MSLeakHunter.{h,m}to the Xcode project. - Somewhere during app initialization (e.g. the
applicationDidFinishLaunchingWithOptions:method of your app delegate.), install the leak hunters that you want to enable:
[MSLeakHunter installLeakHunter:[MSViewControllerLeakHunter class]];- Make sure
MSVCLeakHunter_ENABLEDis set to 1 inMSVCLeakHunter.h
- When you run the app with a leak hunter enabled, and it finds a possible object that is leaking, this is what you'll see:
This other tool lets you debug a leak once you know it exists. It provides a very simple way to make the debugger stop on a breakpoint every time one of the 4 memory management methods is called on the object that you're interested in monitoring. This should help you find out where that extra -retain call is coming from, or who is retaining that object but never releasing it, etc.
Using it is as simple as calling this method declared in MSLeakHunterRetainBreakpointsHelper.h with the object that you want to monitor:
ms_enableMemoryManagementMethodBreakpointsOnObject(object);After this call, the debugger will stop the application whenever -retain, -release, -autorelease, or -dealloc is called on that object. If you go up the stack, you will be able to see who caused the call to those methods and hopefully that will help you debug memory managament problems in your app.
- Note:
MSLeakHunterRetainBreakpointsHelper.mhas to be compiled without ARC. If your project uses ARC, refer to this tutorial to know how to disable ARC only for that file.
MSZombieHunter works similarly to setting NSZombieEnabled, but you can enable it with a class method call:
+[MSZombieHunter enable];From that point on, if an object is sent a message after it's deallocated, it will throw an exception that you can catch and know inmediately when it happened. This is what it looks like:
Important note
Enabling MSZombieHunter makes all objects stay alive when they receive the dealloc message, which increases the memory usage of the application exponentially. For this reason it's only advised to enable it on the simulator and when trying to debug an EXC_BAD_ACCESS crash.
MSLeakHunteris compatible with ARC and non-ARC projects.
If you look at the implementation in MSViewControllerLeakHunter.m, it's very naive. All it does is swizzle some methods for every UIViewController instance to discover when a view controller disappear from screen( it gets a viewDidDisappear: call ), but isn't deallocated after a certain period of time.
If this happens, it doesn't guarantee 100% that the view controller leaked. For example, if it's inside a UITabBarController, it may disappear when you select another tab, but it's still retained by the tabbar, and it hasn't leaked.
But it will help you discover, for example, view controllers that you push onto a navigation controller stack, and aren't deallocated when you pop them tapping on the back button.
In the case where you have something like a navigation controller that is shown modally, and then the whole stack goes away when the modal is closed, you may want to tweak the value of kMSVCLeakHunterDisappearAndDeallocateMaxInterval ( see MSViewControllerLeakHunter.h ) to give MSViewControllerLeakHunter enough margin to avoid a false positive. Otherwise, you may see a log for a possible leak of the controllers at the bottom of the stack if the modal takes longer to be closed.
Copyright 2012 MindSnacks
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.