I could really use some help on this one:
One of my Gideros apps, Fly Fishing Simulator, has been out a year and doing better than expected. Lately I'm hearing from a few users who report using the app, liking it, then making an in-app purchase of all the paid features, and then having the app crash on start-up thereafter. Understandably, they're not happy. It's a tiny percentage of the customers, but it's a very serious issue for those effected. If it's effecting any non-paying users I haven't heard from them.
Here's where it gets strange: If a bug in the paid features is causing it, or if the apps data on the device has become corrupt, then uninstalling and reinstalling it should restore it to the state it was in prior to the purchase, acting like a newly installed copy with no purchased content, and I'd expect the app to work again, at least until they restored their purchased content. That's not the case. Even after uninstalling and reinstalling the app crashes a moment into the main menu.
This lead me to suspect that iOS may not really remove all traces of an uninstalled app, such that some invalid data about how the device will run the app may remain in place, so the problem persists after removal and reinstallation. Or possibly the fact that this is reported after a purchase is a red herring, not relevant to the crash at all.
iTunesConnect shows me several new crashes in iOS 8.1, so maybe the trigger is iOS updates that don't get along with something in the code. The most common crash report I see in iTunesConnect looks like this:
Thread 0 Crashed:
0 libobjc.A.dylib 0x2feacf57 objc_msgSend + 23
1 Foundation 0x2349959b __NSThreadPerformPerform + 383
2 CoreFoundation 0x2275058d __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 13
3 CoreFoundation 0x2274f99b __CFRunLoopDoSources0 + 215
4 CoreFoundation 0x2274e001 __CFRunLoopRun + 769
5 CoreFoundation 0x2269c61d CFRunLoopRunSpecific + 473
6 CoreFoundation 0x2269c42f CFRunLoopRunInMode + 103
7 GraphicsServices 0x29a040a5 GSEventRunModal + 133
8 UIKit 0x25c86805 UIApplicationMain + 1437
9 ffs 0x00076c23 0x71000 + 23587
10 ffs 0x00076bd4 0x71000 + 23508
Symbolicating the ffs entries just points to main.m line 12, and I fail to see anything helpful.
The second most common crash log looks like this:
Thread 0 Crashed:
0 ??? 0000000000 0 + 0
1 ffs 0x00123388 0x4d000 + 877448
2 libsystem_c.dylib 0x33e88192 __cxa_finalize_ranges + 278
3 libsystem_c.dylib 0x33e47b44 exit + 12
4 UIKit 0x29711056 -[UIApplication _terminateWithStatus:] + 350
5 UIKit 0x298f6162 -[UIApplication _handleApplicationDectivationWithScene:shouldForceExit:transitionContext:completion:] + 2518
6 UIKit 0x298f181c -[UIApplication workspaceShouldExit:] + 140
7 FrontBoardServices 0x2c9340e8 __31-[FBSSerialQueue performAsync:]_block_invoke + 12
8 CoreFoundation 0x261ba5b4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12
9 CoreFoundation 0x261b9878 __CFRunLoopDoBlocks + 216
10 CoreFoundation 0x261b7ffa __CFRunLoopRun + 762
11 CoreFoundation 0x26106620 CFRunLoopRunSpecific + 476
12 CoreFoundation 0x26106432 CFRunLoopRunInMode + 106
13 GraphicsServices 0x2d4b40a8 GSEventRunModal + 136
14 UIKit 0x296f0808 UIApplicationMain + 1440
15 ffs 0x00052c26 0x4d000 + 23590
16 ffs 0x00052bd8 0x4d000 + 23512
The line 1 ffs symbolicates to _fwalk in fwalk.c, which means nothing to me, but line 3 is a call to 'exit' which I understand means there's a Lua error according discussion of a similar crash trace at:
http://giderosmobile.com/forum/discussion/4368/crash-using-amazon-insights/p1That discussion attributes the crash to the use of the print() function, but that's an iOS 7 crash and mine is only showing up on iOS 8.
Does anyone have any thoughts on the issue, or even on how/where to look further?
Paul
Comments
It is possible that the crash is due to the Lua error, and the new version (since 2015.04.18 I think) throws platform specific exceptions on lua errors, so the error is shown in the stack/error message
additionally you could integrate any third party crash analytics, like Crashlytics (it's free and will collect crash reports automatically)
I had a similar issue with No Brakes, where a new version of the game would crash for some users. After a painful (but expedited) update with Crashlytics integrated I found the issue quickly; the very first iteration of the game was incompatible with the last. So users that installed the first version, didn't update the game for six months and THEN decided to update, got the error. I wouldn't have been able to find that (before going insane) without granular crash reports.
This is the plugin I use (it's a bit old, but compatible with the latest SDK from Crashlytics): https://github.com/bowerhaus/BhCrashlytics
Niclas