mattdyoung
commented
3 years ago Hi @Augustyniak
Thanks for your thoughts. The challenge with OOM detection on iOS is that Apple doesn't provide an event hook for out of memory events. Bugsnag relies on our own heuristic to identify during app re-launch whether the previous termination of the app was an unexpected termination by the OS watchdog. We can identify several other known reasons the OS may kill the app such as device reboot, app upgrade, app hang on main thread, and we send an Out Of Memory error report that the app was likely terminated by the operating system while in the foreground if all other detectable causes have been ruled out.
For an OOM crash, we can't run any code at crash time and it's hard to predict in advance when a termination is likely to happen. So in terms of capturing breadcrumbs leading up to an OOM it's a balance between what would be useful to diagnose and what would be resource heavy to capture, as we don't want to have any significant impact app performance where the app may not terminate.
In theory leaks and retain cycles could be identified by scanning the heap memory, but we'd need to suspend threads when scanning which would cause a noticeable hang, and we'd need to determine when to perform a scan (possibly relying on memory warning notifications). And even if we detect a leak, identifying the root cause might need the stack trace at time of allocation and memory graph which can't reasonably be tracked in production apps.
We'd suggest continuing to consider which breadcrumbs are most useful to capture the application state, such as those to track the view controller lifecycle, and trying to replicate that state when profiling in Xcode.
We're discussing this internally to consider whether there is any other information we could feasibly capture in OOM reports to help with diagnosing these issues.
Augustyniak
sethfri
luke-belton
firatagdas
hovox
nickdowell
Description
It's hard to tell what the reason for a given Bugsnag OOM crash was - whether a crash was happened by a memory leak, a retain cycle or just a high memory usage caused but the lack of optimizations.
Describe the solution you'd like A way to tell whether a given OOM crash was a result of normal app usage (where the applications just happens to consume too much memory because of the lack of optimizations) or whether there is a memory leak / retain cycle somewhere in the app.
Describe alternatives you've considered Using Xcode instruments to profile the app - one can profile only a small subsets of all of the possible applications' configurations that production users experience. Looking at a Bugsnag report - even with a lot of breadcrumbs in it - it's hard to replicate the state a user was in and be able to tell whether their OOM crash was a result of a retain cycle / memory leak.
Additional context
I do not have a clear idea for how this could be implemented but I wonder whether Bugsnag team has any suggestions / tips / plans for features that could make it easier to detect whether a given OOM crash was a result of a memory leak or a retain cycle.