Now that we’re beta testing and able to symbolicate our crash logs, let’s look into one of the crashes that they helped me solve in version 1.0 of Twitterrific.
The crash was happening during the posting of a notification. The backtrace looked something like this:
Program received signal: “EXC_BAD_ACCESS”. #0 0x300c87ec in objc_msgSend #1 0x30675b0e in _nsnote_callback #2 0x3025380c in _CFXNotificationPostNotification #3 0x30673f46 in -[NSNotificationCenter postNotificationName:object:userInfo:] #4 0x3067aa00 in -[NSNotificationCenter postNotificationName:object:] #5 0x000029fe in -[TwitterrificTouchAppDelegate startTweetRefreshWithMessagesAndFavorites:] at TwitterrificTouchAppDelegate.m:183
The method that initiated the crash was sending IFStartTweetsNotification. This notification allows several views in the UI to reconfigure themselves while the application is refreshing.
One of those views is the toolpad that you see at the bottom of the detailed tweet view. It is a subclass of UIView and is instantiated like this:
- (id)initWithFrame:(CGRect)frame;
{
self = [super initWithFrame:frame];
if (self)
{
...
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(refreshStarted) name:IFStartTweetsNotification object:nil];
}
}
When the view was being freed, this code was being used:
- (void)dealloc
{
...
[super dealloc];
}
I had looked at all of my code and was so convinced that this was a UIKit problem that I filed a Radar. But it turns out that it really was my fault: I had overlooked this little bit of code that gets defined when you create a new view controller:
- (void)didReceiveMemoryWarning {
[super didReceiveMemoryWarning]; // Releases the view if it doesn't have a superview
// Release anything that's not essential, such as cached data
}
Simple enough to understand: whenever the system determines that it is running low on memory, it starts to call these methods. The default implementation is to free a view if it’s not a part of the current view hierarchy.
With a desktop application, views are never released without an explicit action. (And it’s particularly hard to free them if they are instantiated via a NIB.) As a result, some of them us have gotten a bit sloppy with our view cleanup code. And that sloppiness is what bit me.
When my toolpad was out of view, as it is when you are looking at the main list, and a memory warning was issued, the detail view was released. Because the toolpad was a subview of that view, it was also released.
So what happens when you send a notification to an object that no longer exists? That backtrace I showed you above.
The fix was painfully easy:
- (void)dealloc
{
[[NSNotificationCenter defaultCenter] removeObserver:self name:IFStartTweetsNotification object:nil];
...
[super dealloc];
}
The lesson to be learned here: if you’re doing any kind of registration or allocation in your init methods, make sure that you have corresponding action in your dealloc method. Even if you don’t really need them on the desktop.
In my next essay, I’ll show you how to clean up memory when getting one of these warnings. It’s not as straightforward as you might think.
Note: If Apple feels that sharing this information is outside of the bounds of the NDA, I’ll be forced to remove this post. If you want, pretend like it’s 1995 and print this out instead of bookmarking it.