There is no GC in iOS
How a bug in ported garbage-collected code trashed our iOS app
21–30 of 30 posts
Re: How a bug in ported garbage-collected code trashed our iOS app
#22Our app uses this method to cache images and we were seeing huge memory leaks due to this bug. Like the example showed, the bug manifested itself in a retain count being incremented on property access. Our solution was something like this: if ([self.data retainCount] != [self.data retainCount]) { [[[self.data release] release] release]; } Written from memory, so excuse any mistakes. First (and only) time I've ever se…
Yeah this is the general idea we went with. We did our best to synchronize around it, but unfortunately we can never have total control, which necessarily introduces race conditions.
I would imagine this is what leads to the 0.4% crash rate I mentioned at the top of the article :-(
Re: How a bug in ported garbage-collected code trashed our iOS app
#23There is no GC in iOS
Thanks for reading the article so thoroughly.
Re: How a bug in ported garbage-collected code trashed our iOS app
#24Earlier quoted context omitted.
I won't argue too strongly on this, as you're far more knowledgable about it than I am. 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.…
I agree with you that the person who wrote this code likely wrote it assuming a GC environment. It was written originally for OS X perhaps, and not updated (with an autorelease, per mikeash's comment) when ported to iOS. Thanks for the article btw - I'm new to OS X/iOS dev and had no idea that ObjC ever had GC support!
As framework code, it was certainly written to be dual-mode. It's possible to write code that behaves correctly with both GC and reference counting. It's a minor pain in the ass because you have to satisfy both sides at once, but it's not all that hard. Because the frameworks can be used in both environments, all (Mac) framework code has to be written this way. There would have been no changes needed to the code when moving it to iOS, at least not related to garbage collection.
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.
Re: How a bug in ported garbage-collected code trashed our iOS app
#25The title confused me: It was redefinition of a GC related function that lead to the bug. It has nothing to do with the existence of a GC on iOS.
Actually not a redefinition, as that function has had the same behavior since it was introduced. It's just code that's incorrect when run with reference counting.
Re: How a bug in ported garbage-collected code trashed our iOS app
#26Earlier quoted context omitted.
I agree with you that the person who wrote this code likely wrote it assuming a GC environment. It was written originally for OS X perhaps, and not updated (with an autorelease, per mikeash's comment) when ported to iOS. Thanks for the article btw - I'm new to OS X/iOS dev and had no idea that ObjC ever had GC support!
As framework code, it was certainly written to be dual-mode. It's possible to write code that behaves correctly with both GC and reference counting. It's a minor pain in the ass because you have to satisfy both sides at once, but it's not all that hard. Because the frameworks can be used in both environments, all (Mac) framework code has to be written this way. There would have been no changes needed to the code when…
Good point. I overlooked the fact that non-GC environments existed on OS X as well, way before iOS.
Re: How a bug in ported garbage-collected code trashed our iOS app
#27Earlier quoted context omitted.
As framework code, it was certainly written to be dual-mode. It's possible to write code that behaves correctly with both GC and reference counting. It's a minor pain in the ass because you have to satisfy both sides at once, but it's not all that hard. Because the frameworks can be used in both environments, all (Mac) framework code has to be written this way. There would have been no changes needed to the code when…
Good point. I overlooked the fact that non-GC environments existed on OS X as well, way before iOS.
In case you're curious about the history (since you said you're new to the platform), garbage collection showed up as an optional feature in Objective-C in OS X 10.5, was effectively discouraged in favor of ARC in 10.7, and officially deprecated in 10.8. Not a terribly long run, sadly. It was a nice idea that didn't work out as well in practice.
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.
Re: How a bug in ported garbage-collected code trashed our iOS app
#28So tl;dr NSURLCache has a memory leak, be careful when using it.. Or?
Re: How a bug in ported garbage-collected code trashed our iOS app
#29What I love about these stories from the trenches isn't just seeing how the mystery gets solved (although that part is great), but seeing the evolution of the investigation -- which might be the more valuable of the two things when it comes to improving your own bug tracking skills.
Re: How a bug in ported garbage-collected code trashed our iOS app
#30Earlier quoted context omitted.
Good point. I overlooked the fact that non-GC environments existed on OS X as well, way before iOS.
In case you're curious about the history (since you said you're new to the platform), garbage collection showed up as an optional feature in Objective-C in OS X 10.5, was effectively discouraged in favor of ARC in 10.7, and officially deprecated in 10.8. Not a terribly long run, sadly. It was a nice idea that didn't work out as well in practice. A single piece of code can potentially work in both environments, but it…
That wasn't pointless at all, though it was a bit rambling j/k :) Comments like yours are the reason I visit HN.