[mikeash]

The 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.

[asarazan]

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.

[mikeash]

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 world:

    [NSMakeCollectable(cfobj) autorelease];

In this case, "obj" was retained inline. They just forgot the autorelease. They could have forgotten it just as easily without garbage collection, and the NSMakeCollectable (which inlines to CFMakeCollectable) call is unrelated, aside from possibly occupying the wrong spot of the original programmer's brain at the wrong moment.

[asarazan]

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.

[nairteashop]

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!

[mikeash]

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.

[nairteashop]

Good point. I overlooked the fact that non-GC environments existed on OS X as well, way before iOS.