App unexpectedly crashes after installation from testflight

Question

Created 4d

Replies 1

Boosts 0

Participants 2

I've an app running for some time in the Appstore now. Recently I had to renew my singing certficicates to be able to publish my app again. I renewed the certificates, updated my provisioning profile and signed a new app version to publish only to find out that the app crashes during the splash screen.

I added new features to the app so my first thought was that there would be an issue there. To test that, I built the latest stable version of the app and signed it with the new profivisioning profile. The result was exactly the same crash as the new build.

My assumption is that the crash is caused by bad signing (?) but I am not sure because I'm lacking experience on that front. I do have a crash report from testflight and logs from the device where the app crashed.

Testflight crash:

TestFlight crashlog

Device error logs:

Device error logs

Hope someone can help my out because I'm at a dead end :(

Boost

Answer 1

DTS Engineer OP

Apple

3d

Thanks for posting the crash report. Consider the backtrace of the crashing thread:

Thread 0 Crashed:
0   libsystem_kernel.dylib        … __pthread_kill + 8
1   libsystem_pthread.dylib       … pthread_kill + 268 (pthread.c:1721)
2   libsystem_c.dylib             … abort + 128 (abort.c:122)
3   Vriendendienstje.Platform.App … 0x10467c000 + 8880352
4   Vriendendienstje.Platform.App … 0x10467c000 + 8363776
5   libsystem_platform.dylib      … _sigtramp + 56 (sigtramp.c:116)
6   libsystem_pthread.dylib       … pthread_kill + 268 (pthread.c:1721)
7   libsystem_c.dylib             … abort + 128 (abort.c:122)
8   Vriendendienstje.Platform.App … 0x10467c000 + 5415188
9   Vriendendienstje.Platform.App … 0x10467c000 + 7536876
10  Vriendendienstje.Platform.App … 0x10467c000 + 8192116
11  Vriendendienstje.Platform.App … 0x10467c000 + 5491396
12  Vriendendienstje.Platform.App … 0x10467c000 + 8620160
13  dyld                          … start + 2724 (dyldMain.cpp:1334)

There’s a lot to unpack here. The immediate cause of the crash is that your code (frame 3) called abort. It’s hard to say why it did that because your code isn’t symbolicated. You’ll need to symbolicate this crash report in order to make progress. See Adding identifiable symbol names to a crash report.

However, frame 5 suggests that your code is running in a signal handler. I usually see this when a developer has decided to use a third-party crash reporter. I strongly recommend against using third-party crash reports, for the reasons I outline in Implementing Your Own Crash Reporter.

This crash report indicates a clear bug in that crash reporter because the signal handler is calling abort and that’s not an async signal safe function.

Looking a level down, the signal handler is running because of some other part of your code (frame 8) is calling abort (frame 7). That’s likely to be the real source of your crash.

So, to summarise:

Remove your third-party crash reporter. That’ll get you a trustworthy crash report.
Then symbolic the crash report to see uncover the identity of the failing code.

Oh, one more thing. I think this is unlikely to be related to TestFlight per se. It’s more likely that any release build of your app will crash this way. See Isolating Code Signing Problems from Build Problems for more on that.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1