2

I'm running into a strange issue whereby an app I'm building crashes shortly after launching as an archived build from TestFlight, but runs without issue when running on the same device directly from Xcode. The application doesn't appear to be terminating fully - if I double-tap the home button, I see what looks like an image of the application in the background from midway through a run, even though the new session crashed long before it would have gotten to the displayed screen. If I then bring the application back to the foreground, it returns to its loading screen and then shuts down again, with a log that looks like this:

Incident Identifier: 983F8E4E-EFE0-4C93-8F46-D223FD86DF14
CrashReporter Key:   3515df1d8c55a27394a78b6efee5f83946ed9a99
Hardware Model:      iPhone7,2
Process:             FileProvider [218]
Path:                /private/var/containers/Bundle/Application/89708FF4-E848-4F49-BC0D-B2DC9EF536C6/Drive.app/PlugIns/FileProvider.appex/FileProvider
Identifier:          com.google.Drive.FileProviderExtension
Version:             4.2017.25202 (4.2017.25202)
Code Type:           ARM-64 (Native)
Role:                Unspecified
Parent Process:      launchd [1]
Coalition:           com.google.Drive.FileProviderExtension [368]




Date/Time:           2017-06-30 22:59:01.2937 -0700
Launch Time:         2017-06-30 22:59:00.7649 -0700
OS Version:          iPhone OS 10.3.2 (14F89)
Report Version:      104


Exception Type:  EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note:  EXC_CORPSE_NOTIFY
Termination Reason: Namespace <0xF>, Code 0xdead10cc
Triggered by Thread:  0

...Any thoughts on what I should be investigating to understand what's going on here?

App is built in C++ using the Cocos2d-x framework.

Thanks! _Kevin

Sid Mhatre
  • 3,272
  • 1
  • 19
  • 38
Kevin Mack
  • 1,174
  • 1
  • 9
  • 20
  • How long ago was the app delivered by TestFlight? – Paulw11 Jul 01 '17 at 07:10
  • About an hour ago. I had previously been testing the app by running on the device directly from Xcode, and then when the new archived binary arrived from TestFlight, I allowed TestFlight to overwrite the binary from Xcode. – Kevin Mack Jul 01 '17 at 07:16
  • Here's some additional information from the log in case it's helpful: (I'm also noticing that crash logs from recent run attempts aren't available from the device - this log is from a crash earlier in the evening, but I've run it since then and not found additional logs. Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 libsystem_kernel.dylib 0x0000000184edb224 mach_msg_trap + 8 1 libsystem_kernel.dylib 0x0000000184edb09c mach_msg + 72 2 CoreFoundation 0x0000000185eace90 __CFRunLoopServiceMachPort + 192 ... – Kevin Mack Jul 01 '17 at 07:19
  • Further info: as a test, we uploaded an older build that had previously been working, and it failed in the same way, so whatever this is appears to be external to the build itself. We're observing it on two separate iOS devices. – Kevin Mack Jul 05 '17 at 14:32
  • This appears to be relevant: https://developer.apple.com/library/content/technotes/tn2151/_index.html "an application has been terminated by the OS because it held on to a file lock or sqlite database lock during suspension". Is it possible that a previous crashed session is still holding a lock and preventing subsequent executions? – Kevin Mack Jul 05 '17 at 16:15

1 Answers1

2

Figured out what was going on, if not yet exactly why. Some of the details posted above turned out to be red herrings as I investigated further. What initially appeared to be a difference in behavior between an archived build and a build launched directly from Xcode was actually a difference in behavior between a debug build and a release build.

The solution was to create a new scheme in Xcode to run a release build (Product->Scheme->Manage Schemes in Xcode 8.3), duplicate my default mobile scheme, and then set the new scheme's Run->Info->Build Configuration to Release.

Once I ran a release build with Xcode attached, I found an error (probably an incorrectly-initialized variable but I'm still investigating) that occurred in release builds only.

The reason why crash logs weren't being generated appears to have been that the error was causing an assertion to trip (the CC_ASSERT macro in Cocos2d-x), so iOS considered the app shutdown to be a legitimate termination and didn't log it as a crash.

Kevin Mack
  • 1,174
  • 1
  • 9
  • 20