Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How a bug in ported garbage-collected code trashed our iOS app

tech.cueup.com

Post reply on HN
Print view View original

11–20 of 30 posts

Re: How a bug in ported garbage-collected code trashed our iOS app

#11

Post by applecore »

asarazan wrote: post #2

I 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…

If you're not monitoring crashes, check out Crashlytics.

http://crashlytics.com/

You'd be surprised what can be detected and caught.

Re: How a bug in ported garbage-collected code trashed our iOS app

#12

Post by asarazan »

applecore wrote: post #11
asarazan wrote: post #2

I 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…

If you're not monitoring crashes, check out Crashlytics. http://crashlytics.com/ You'd be surprised what can be detected and caught.

We've been using Crittercism in the past and recently switched to Crashlytics, unfortunately memory crashes are one of the few exceptions (hah) to the rule, as they are SIGKILLs from the OS.

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.

Re: How a bug in ported garbage-collected code trashed our iOS app

#13

Post by asarazan »

idunno246 wrote: post #9
asarazan wrote: post #2

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

We do this for various other reasons (clearing possibly corrupted state, etc), but we've never uploaded the statistics to the servers. We may begin doing this in the future.

Re: How a bug in ported garbage-collected code trashed our iOS app

#17

Post by asarazan »

gte910h wrote: post #15

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

I was going for more of a sly joke with the title, but it appears to have not gone over well. I now regret my decision.

Re: How a bug in ported garbage-collected code trashed our iOS app

#18

Post by nairteashop »

asarazan wrote: post #10
mikeash wrote: post #8

Earlier quoted context omitted.

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

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!

Re: How a bug in ported garbage-collected code trashed our iOS app

#19

Post by jkubicek »

Our 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 seen a legitimate use for `retainCount`. @bbum would be proud (or perhaps horrified).

Re: How a bug in ported garbage-collected code trashed our iOS app

#20

Post by bennyg »

jkubicek wrote: post #19

Our 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…

So in the first line, it has 1 and then checking to see if it's equal bumps it to 2 allocs, and finally the third call, to begin releasing, brings it to 3 (then removal of all 3)?

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.

Post reply on HN