app/
Update: Sept 9, 2009: Mac OS 10.6 Snow Leopard now has this feature built into Instruments! In Xcode, choose “Run -> Run with Performance Tool -> Zombies”, and repeat your steps that cause the crash. Easy as pie. Read on if you don’t have Snow Leopard…
Mac OS 10.5 Leopard has a great new developer app called Instruments.
It can easily be used to debug those “random crashers” in your application caused by too many -release or -autorelease calls. Let’s see how.
If you want to follow along, download this project: CrashTestDummy.zip
Open it up in Xcode.
The nib has two outlets in it: a basic NSObject called testObject and button setup to invoke the following code:
- (IBAction)buttonCrashTestAction:(id)sender {
// We are going to autorelease the testObject too many times..
[testObject autorelease];
}
So, we will hit the button a few times and we should get a crash. Compile the app with the Debug target. Start Instruments, and select the Object Allocations template:
Hit the purple “i” next to the instruments to bring up the inspector for it, and be sure to check “Record reference counts”, as seen below:
Cool. Click “Launch Executable” and select “Choose Executable”, and find CrashTestDummy.app from the built directory.
While you have the Open Panel up, add the environment variable NSZombieEnabled and set it to YES (sort of an optional step):
Hit Open, if you haven’t already done so.
Hit “Record” in instruments, which will start the app, and click the “Crash Test” button a few times until the app crashes.
Alright! Fire up Console.app and look for a line like this:
The important part is the address, 0x150d40, in this case.
In Instruments, move the mouse to the right of “All Allocations” and a little triangle appears:
Click on it to see all the allocations.
In the lower right hand corner of instruments click on the magnifying glass in the NSSearchField and select “Address”:
Type in your address, and you should see all allocations at that address:
Now, why so many? Well, addresses are reused. Chances are, the last allocation is your object, and sure enough, it is, since we know we are over releasing an NSObject instance. Click on that item, and you’ll see the history for it. Scroll to the bottom to see just the history for that NSObject:
Now! You should be able to figure out which release probably shouldn’t be there. We know it is #19 from our demo, but sometimes it isn’t that easy to figure out. Select #19′s row and then click the little gray arrow to next to its address (or whatever yours is), and then click on this button at the bottom of instruments to show the stack trace / extended detail:
You can then see when that “bad release” happened. Click on the thumb below for a full size screen shot of it.
Ahh! Way cool. Of course, this was a simple and easy test case.
Happy debugging :)
corbin
＋＋＋＋＋