Changes for this release are:
- Fixed compatibility issue with a future version of Mac OS X (the bald-looking cat).
- Enabled Objective-C garbage collection.
I defined a category method of
NSMutableArray as part of my library of commonly-used stuff. Apparently Apple defined a new method with the same exact name with a slightly different behavior, causing News Anchor to crash because it relies on the behavior that I implemented. Luckily this was easily discovered when I run News Anchor on the beta OS X release and easily fixed by renaming my category method.
The method was
[NSMutableArray setObject:atIndex:] and I used it to manipulate a sparse-like array. That is, when the index is invalid then it will automatically add
NSNull “filler” instances as needed to set the object at the desired index. This is coupled with an accompanying category method
[NSArray objectAtCheckedIndex:] that returns nil should it is receives an invalid index or it encounters an
NSNull object at the desired index. I’ve fixed this by renaming my category method to
[NSMutableArray setObject:atCheckedIndex:] to avoid naming collision with the method that likely introduced in that future version of OS X.
In News Anchor’s crash logs, I often encountered crashes that points to problems in Apple’s XML parsing libraries. It looks like some HTML documents or RSS feed content causes the library to double-free some nodes, which in turn crashes News Anchor when parsing it. The issue is buried deep within NSXMLParser libraries and there isn’t much that I can do to solve it.
Here is an excerpt of the crash log if you’re keen to find out more. The crash is obviously somewhere inside NSXML stuff.
0 libsystem_kernel.dylib 0x00007fff8570ece2 __pthread_kill + 10 1 libsystem_c.dylib 0x00007fff827157d2 pthread_kill + 95 2 libsystem_c.dylib 0x00007fff82706a7a abort + 143 3 libsystem_c.dylib 0x00007fff827284ac szone_error + 459 4 libsystem_c.dylib 0x00007fff82729e2a free_tiny_botch + 93 5 com.apple.CoreFoundation 0x00007fff8308c2cf __CFCSetMakeBitmap + 895 6 com.apple.CoreFoundation 0x00007fff830ef7e1 CFCharacterSetUnion + 1441 7 com.apple.Foundation 0x00007fff8497e351 +[NSXMLFidelityNode setObjectValuePreservingEntitiesForNode:string:] + 265 8 com.apple.Foundation 0x00007fff849772b6 +[NSXMLElement _elementFromTidyDoc:element:encoding:elementClass:nodeClass:] + 9043 9 com.apple.Foundation 0x00007fff849776cd +[NSXMLElement _elementFromTidyDoc:element:encoding:elementClass:nodeClass:] + 10090 10 com.apple.Foundation 0x00007fff84970ab8 -[NSXMLDocument _initWithLibTidyDoc:child:encoding:] + 1375 11 com.apple.Foundation 0x00007fff84973580 -[NSXMLDocument _tidyWithData:error:isXML:detectedEncoding:] + 2164 12 com.apple.Foundation 0x00007fff848414cc -[NSXMLDocument initWithData:options:error:] + 533 13 com.apple.Foundation 0x00007fff84973c71 -[NSXMLDocument initWithXMLString:options:error:] + 347
Yes, I could switch to a different parser or move the parser to a different process, but these will be somewhat overkill. Using another XML/HTML parser doesn’t guarantee that it won’t choke and crash on other kinds of documents – moreover I don’t have any sample documents that NSXMLParser will surely crash on, which makes it really hard to validate my choice of replacement XML parser. Moving the parser to a separate process involves writing a lot of glue code – News Anchor still need to run on Snow Leopard and XPC Services that helps to do this is only available starting from Lion.
Since the issue was un-fixable (being in Apple’s code) and un-reproducable (not having the offending XML input to test it out with), my best bet to work around this memory issue is to enable garbage collection. Hopefully the garbage collector will cancel out NSXMLParser’s problem and thus not causing News Anchor to crash when it encounters less-than-favorable input. I’ve done some testing and there isn’t any noticeable performance degradation caused by the switch.
Anyway, please download the beta and let us know if you find any issues with it.