IOS: Crashlytics Crash Reports and Free RAM

Question

In one of our iPhone apps, we received several Crashlytics crashes that we have not yet been able to reproduce. However, upon closer inspection, I noticed a bit of a trend ...

---

Failure 1: - [UINavigationTransitionView _notifyDelegateTransitionDidStopWithContext:]

Free RAM: 10%

---

Failure 2: - [UINavigationTransitionView _notifyDelegateTransitionDidStopWithContext:]

Free RAM: 8%

---

Crash 3: HostBase :: lock ()

Free RAM: 8%

---

Failure 4: - [UINavigationTransitionView _notifyDelegateTransitionDidStopWithContext:]

Free RAM: 22%

---

Does the amount of free RAM mean anything? Can we be sure that these are actual crashes, and not our application, which kills the OS due to low memory? Does Crashlytics provide crash reports if an application crashes in the background?

Added several stack traces ...

Exclusion Type: SIGSEGV, Nav Crashes

0 libobjc.A.dylib objc_msgSend + 15 1 UIKit ✭ -[UINavigationTransitionView _notifyDelegateTransitionDidStopWithContext:] + 274 2 UIKit -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 158 3 UIKit -[UIViewAnimationState animationDidStop:finished:] + 50 4 QuartzCore CA::Layer::run_animation_callbacks(void*) + 208 5 libdispatch.dylib _dispatch_client_callout + 22 6 libdispatch.dylib _dispatch_main_queue_callback_4CF$VARIANT$mp + 224 7 CoreFoundation __CFRunLoopRun + 1290 8 CoreFoundation CFRunLoopRunSpecific + 356 9 CoreFoundation CFRunLoopRunInMode + 104 10 GraphicsServices GSEventRunModal + 74 11 UIKit UIApplicationMain + 1120 

Exception Type: SIGSEGV, HostLock Fails

 0 libobjc.A.dylib objc_msgSend + 15 1 CFNetwork ✭ HostBase::lock() + 14 2 CFNetwork DispatchHost::performInvocation(void const*) + 12 3 CFNetwork __setupTCPConnection_block_invoke_2 + 290 4 ... libsystem_network.dylib __tcp_connection_notify_complete_block_invoke_1 + 18 7 libsystem_c.dylib _pthread_wqthread + 294 

Answer 1

8% of memory can be a lot, I doubt very much that this is a problem. I don’t know if they send crashes while running in the background, you should ask them directly since their SDK is not open source.

Both stacks of the exception stack added a hint of a memory problem.

The first looks like it is trying to call a delegate at the end of the animation of an object that no longer exists.

The second is similar to a similar problem when the completion block accesses the deleted object. This way you can check your blocks for such patterns.