HexColorPicker.m, circa one hour ago:
- (void)hcp_checkForUpdateUIFinish:(NSDictionary *)updateDict {
/* Note: updateDict is by call site convention
already passed a retained dictionary */
NSString *verdict = [[updateDict objectForKey:HexColorPickerUpdateVerdict] copy];
[updateDict release];
/* .. */
if ([verdict isEqualToString:HexColorPickerUpdateNewerAvailable]) {
NSString *infourl = [updateDict objectForKey:HexColorPickerUpdateNewerURL];
if (updateInfoURL) [updateInfoURL release];
updateInfoURL = [[NSURL alloc] initWithString:infourl];
/* .. */
}
[verdict release];
}
Did you spot it? If a newer version is available, you’re running Hex Color Picker outside of garbage collection and you’re unlucky, updateDict won’t just be released prematurely, but also be dealloced before an attempt is made to pull some more data (the new version URL) out of it. That might leave updateDict pointing to nil, messaging nil also returns nil which makes infourl nil and we end up feeding it to NSURL’s - initWithString:. Which produces an exception. Which takes down the entire application Hex Color Picker is hosted in.
Ruh-roh.
I’ve fixed this and pushed Hex Color Picker 1.6.1, which, in a delicious fit of irony, will expose every single Hex Color Picker user (of a version of such a vintage that it has the bug in it) to the conditions that trigger the bug.
I am reminded of O’Toole’s Commentary on Murphy’s Law: Murphy was an optimist.
Autorelease is your friend :)
By Joel Bernstein · 2010.02.09 01:34
Why?
By Chris Suter · 2010.02.09 02:06
Actually, Chris is right.
Releasing updateDict doesn’t set it to nil, but whatever’s sitting in that memory location afterwards might happen to accept the objectForKey: message and return 0. Even if it doesn’t, it’ll just throw an exception a few lines earlier.
By Joel Bernstein · 2010.02.09 02:19
Guys. After midnight, I am not the fount of all memory management knowledge, and even so that was a typo.
By Jesper · 2010.02.09 07:11
Looks like the kind of problem the static analyser might catch.
Did you use that or just spotted it randomly?
By ssp · 2010.02.09 11:02
Actually, the Clang Static Analyzer doesn’t catch this at all when I do Build and Analyze, or enable the build Analyze step for the 10.5+ target.
I spotted it through two crash reports, reported in both cases by Coda to Panic and then sent my way by helpful support people over there. (I actually got the first a while ago; I told the reporter to upgrade and went to stare down the code and just didn’t see the bug. It took the second report to make me spot it.) I reciprocated by letting them know that they might get more of these now that this went live.
By Jesper · 2010.02.09 21:21