Hacker News new | ask | show | jobs
by asarazan 4746 days ago
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 dedicated QA that was keeping pretty solid track of them all, and they piled up.

In our case I think it was worth it.

2 comments

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