How a bug in ported garbage-collected code trashed our iOS app
1–10 of 30 posts
Re: How a bug in ported garbage-collected code trashed our iOS app
#2I should note that, while we saw something like 0.4% increased crash rate, we actually don't have a number to compare it against for memory crashes.
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.
Re: How a bug in ported garbage-collected code trashed our iOS app
#3Aren't you living dangerously by still using garbage collection on iOS at this point? Apple keep making dire statements about how everyone needs to stop using it, so I'd be worried that iOS8 will just remove it entirely, meaning apps that use GC just wouldn't work at all on that OS...
Re: How a bug in ported garbage-collected code trashed our iOS app
#4Aren't you living dangerously by still using garbage collection on iOS at this point? Apple keep making dire statements about how everyone needs to stop using it, so I'd be worried that iOS8 will just remove it entirely, meaning apps that use GC just wouldn't work at all on that OS...
I should clarify. iOS does not have garbage collection and has never had garbage collection. The root of this bug is in old legacy cruft from the garbage collected days of OSX. The code is dormant in a lot of old CoreFoundation classes, and still causes unexpected behavior from time to time.
Re: How a bug in ported garbage-collected code trashed our iOS app
#5Aren't you living dangerously by still using garbage collection on iOS at this point? Apple keep making dire statements about how everyone needs to stop using it, so I'd be worried that iOS8 will just remove it entirely, meaning apps that use GC just wouldn't work at all on that OS...
ObjC garbage collection never existed on iOS. The issue was related to framework code that was written by Apple for an ObjC-GC environment (probably Mac OS X) and ported to a non-GC environment (iOS).
Re: How a bug in ported garbage-collected code trashed our iOS app
#6The link to garbage collection is a bit odd. The garbage collector does not, of course, exist on iOS, and this bug has nothing to do with garbage collection. It's just a memory leak due to bad manual memory management. It just so happens that this leak is in code that's written to also work when garbage collection is on, but the leak isn't due to, or even related to, garbage collection.
This may be nitpicking, but it made it hard for me to pay attention to the real meat of the thing.
Re: How a bug in ported garbage-collected code trashed our iOS app
#7The link to garbage collection is a bit odd. The garbage collector does not, of course, exist on iOS, and this bug has nothing to do with garbage collection. It's just a memory leak due to bad manual memory management. It just so happens that this leak is in code that's written to also work when garbage collection is on, but the leak isn't due to, or even related to, garbage collection. This may be nitpicking, but it…
I would disagree pretty strongly with that. The function CFMakeCollectable is explicitly a function for dealing with the garbage collector, and its unpredictability in non-garbage-collected code is the direct cause of the bug.
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.
Re: How a bug in ported garbage-collected code trashed our iOS app
#8The link to garbage collection is a bit odd. The garbage collector does not, of course, exist on iOS, and this bug has nothing to do with garbage collection. It's just a memory leak due to bad manual memory management. It just so happens that this leak is in code that's written to also work when garbage collection is on, but the leak isn't due to, or even related to, garbage collection. This may be nitpicking, but it…
I would disagree pretty strongly with that. The function CFMakeCollectable is explicitly a function for dealing with the garbage collector, and its unpredictability in non-garbage-collected code is the direct cause of the bug. 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…
There's no unpredictability. CFMakeCollectable does nothing when not using garbage collection. That's explicitly documented.
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];
Re: How a bug in ported garbage-collected code trashed our iOS app
#9I should note that, while we saw something like 0.4% increased crash rate, we actually don't have a number to compare it against for memory crashes. 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 dedi…
We touched a file on disk and deleted it on entering background. If it exists at startup, last run was a crash. Not a great solution, but gave us some idea of # of crashes not caught by our crash reporting.
Re: How a bug in ported garbage-collected code trashed our iOS app
#10Earlier quoted context omitted.
I would disagree pretty strongly with that. The function CFMakeCollectable is explicitly a function for dealing with the garbage collector, and its unpredictability in non-garbage-collected code is the direct cause of the bug. 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…
There's no unpredictability. CFMakeCollectable does nothing when not using garbage collection. That's explicitly documented. Without GC, this code would have been written as simply: CFRetain(data); And the same bug would manifest. The bug is just a missing release call. 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 wor…
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. 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.