How a bug in ported garbage-collected code trashed our iOS app(tech.cueup.com) |
How a bug in ported garbage-collected code trashed our iOS app(tech.cueup.com) |
This is because if memory usage gets too high, the OS will send a kill signal to the process, which can be neither detected nor caught.
This means that in our original decision to use this fix, all we had was anecdotal evidence of untraceable crashes. Luckily we had dedicated QA that was keeping pretty solid track of them all, and they piled up.
In our case I think it was worth it.
You'd be surprised what can be detected and caught.
Another commenter recommended touching a file at launch and at sleep to track untraceable crashes, which we do for various other reasons, but don't upload the stats. We may begin doing this.
if ([self.data retainCount] != [self.data retainCount]) {
[[[self.data release] release] release];
}
That's super weird - I have yet to encounter something along these lines in my Cocoa work so far. Solid idea to beat the system there. I just hope it's got a nice comment above it haha.
I would imagine this is what leads to the 0.4% crash rate I mentioned at the top of the article :-(
This may be nitpicking, but it made it hard for me to pay attention to the real meat of the thing.
Doesn't it make sense to say that without the existence of Apple GC, the bug never would have existed? Doesn't that at least somewhat justify the title?
edit: Furthermore the original intent of including garbage collection in the title was as an ironic twist based on the fact that ios has never had garbage collection. Maybe that didn't convey as well as I would have liked.
Without GC, this code would have been written as simply:
CFRetain(data);
Edit: I'd assume they were going for the standard pattern for code that needs to be both GC and non-GC for bridging CF objects out into the Cocoa world:
[NSMakeCollectable(cfobj) autorelease];
However, imo the intention and semantics behind a call like CFMakeCollectable implies a transfer of ownership to an external system. A newbie Apple coder could be forgiven for thinking it would still transfer ownership in RC environments, just to the autorelease pool instead of a collector. In all likelihood this is what happened. An intern got at the code and didn't know the details about GC.
Obviously the point stands that this interpretation is well-documented to be false, but its naming is definitely misleading.
Double edit: I see from your edit that some of my basic assumptions about CFMakeCollectable were wrong, having never actually worked with it. My bad.
Thanks for the article btw - I'm new to OS X/iOS dev and had no idea that ObjC ever had GC support!
They just forgot an autorelease. This would cause the same problems on the Mac as on iOS for non-GC apps (which is, to a decent approximation, all of them). Given that the API in question pre-dates Objective-C garbage collection by about half a decade, and the code in question probably does as well, I really don't think garbage collection can be related to this in any way beyond one GC-related call being near the bug.
A single piece of code can potentially work in both environments, but it needs to be written with that in mind, so binaries are annotated with their GC support. Any given library or plugin can be non-GC, GC-only, or GC-optional. Non-GC libraries can only load into non-GC apps, and GC-only libraries can only load into GC apps. GC-optional libraries can load into either, but are annoying to write as I mentioned. Since the system has to support both, all system libraries had to be made GC-optional.
In addition to the usual teething bugs with the collector itself, all the libraries sprouted bugs in GC mode due to the conversion, which made garbage collection in ObjC a bit too interesting to really be nice to use.
That ends today's long, pointless, rambling comment.