Container App Crashing: More Information Needed from Crashlytics

Question

The development team I work with has produced a container app that serves up the client's mobile site. We can see that the container app is crashing on iOS 10 but don't have much information about the cause of the problem. The stack trace doesn't point to much other than a possible issue with Webkit and JS Core:

Crashed: com.apple.main-thread
0  WebKit                         0x19673fddc API::Object::ref() + 2
1  WebKit                         0x1968bb35c WebKit::WebPageProxy::didStartProvisionalLoadForFrame(unsigned long long, unsigned long long, WTF::String const&, WTF::String const&, WebKit::UserData const&) + 192
2  WebKit                         0x1968d621c void IPC::handleMessage<Messages::WebPageProxy::DidStartProvisionalLoadForFrame, WebKit::WebPageProxy, void (WebKit::WebPageProxy::*)(unsigned long long, unsigned long long, WTF::String const&, WTF::String const&, WebKit::UserData const&)>(IPC::MessageDecoder&, WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(unsigned long long, unsigned long long, WTF::String const&, WTF::String const&, WebKit::UserData const&)) + 100
3  WebKit                         0x1967941d0 IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::MessageDecoder&) + 120
4  WebKit                         0x196917614 WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::MessageDecoder&) + 32
5  WebKit                         0x19675d3e8 IPC::Connection::dispatchMessage(std::__1::unique_ptr<IPC::MessageDecoder, std::__1::default_delete<IPC::MessageDecoder> >) + 160
6  WebKit                         0x19675fa00 IPC::Connection::dispatchOneMessage() + 204
7  JavaScriptCore                 0x191b4c834 WTF::RunLoop::performWork() + 172
8  JavaScriptCore                 0x191b4ca60 WTF::RunLoop::performWork(void*) + 36
9  CoreFoundation                 0x18d332b5c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
10 CoreFoundation                 0x18d3324a4 __CFRunLoopDoSources0 + 524
11 CoreFoundation                 0x18d3300a4 __CFRunLoopRun + 804
12 CoreFoundation                 0x18d25e2b8 CFRunLoopRunSpecific + 444
13 GraphicsServices               0x18ed12198 GSEventRunModal + 180
14 UIKit                          0x1932a57fc -[UIApplication _run] + 684
15 UIKit                          0x1932a0534 UIApplicationMain + 208
16 Betfred                        0x10005c250 main (main.m:16)
17 libdispatch.dylib              0x18c2415b8 (Missing)

Nobody internal has been able to get the app to crash reliably (including the test team who are using it around the clock) and as far as we know, there are no issues with the mobile site.

I've been asked to look into the issue but am at a bit of a loss as I can't diagnose and fix something if I can't consistently get it to break.

Is there any way we could get more information from Crashlytics about the cause of this crash?

Answer 1

Mike from Fabric here and crashes like this can be tough to track down. You'd need to release a new version of your app, but there are three different ways to get additional information.

1) Add custom keys, for example to track which pages are being loaded or which endpoints are being hit, can provide additional context:

- (void)setObjectValue:(id)value forKey:(NSString *)key;

// calls -description on value, perfect for NSStrings!
- (void)setIntValue:(int)value forKey:(NSString *)key;

- (void)setBoolValue:(BOOL)value forKey:(NSString *)key;

- (void)setFloatValue:(float)value forKey:(NSString *)key;

2) Add custom logs as a form of breadcrumbs to make it easier to reproduce the steps a user is doing in the lead-up to the crash:

CLS_LOG(@"User clicked on menu %@", attributesDict);

3) Add user identifiers:

[CrashlyticsKit setUserIdentifier:@"123456789"];
[CrashlyticsKit setUserEmail:@"[email protected]"];
[CrashlyticsKit setUserName:@"Awesome AppUser"];

When all else fails, reaching out to the user to get additional information can also help track it down.