iOS app crash - EXC_CRASH (SIGABRT)

Question

Created Jan ’24

Replies 3

Boosts 0

Participants 2

Hey there! We recently release our app, and spotted a couple of crash reports in the last 2 released versions. It happened to 2 different users with the same iOS major version:

iPhone15.3, OS 17.1.2
iPhone15.3, OS 17.2.1

Attaching 2 different crash reports on (what seems to be) the same issue.
(the app name is changed for the security reasons):

After reading multiple StackOverflow, Github and Apple support threads on similar issue I wanted to add a couple of notes for the context:

our app is written in TypeScript
it's packed via Capacitor into iOS and Android bundles and is served via built-in browser
re/ CameraUI from the crash report - we have a functionality of picking the image from gallery, or using the camera to take a photo, if it's related

re/ permissions for that - we have:
- <key>Privacy - Photo Library Usage Description</key>
- <key>Privacy - Camera Usage Description</key>
in the Info.plist file set to:
- <string>$(PRODUCT_NAME) photo use</string> and
- <string>$(PRODUCT_NAME) camera use</string> respectively

Would appreciate any clues and ideas! Thanks in advance!

Boost

Answer 1

MaxDonchenko OP

Jan ’24

For some reason I can't attach files with crash report, so here are the gists:

0

Answer 2

DTS Engineer OP

Apple

Jan ’24

All of the following comments are relative to the first crash report you posted, but a cursory check on the second one indicates it’s something similar.

You have a third-party crash reporter installed (see thread 6) and that’s messing up your crash reports. I talk about this issue in gory detail in Implementing Your Own Crash Reporter.

How do I know this? Well, consider this:

Exception Type:  EXC_CRASH (SIGABRT)

It indicates that your app trapped, that is, crash itself by calling abort [1]. So lets look at the crashing thread:

Thread 0 name:
Thread 0 Crashed:
0   libsystem_kernel.dylib … mach_msg2_trap + 8 (:-1)
1   libsystem_kernel.dylib … mach_msg2_internal + 80 (mach_msg.c:201)
2   libsystem_kernel.dylib … mach_msg_overwrite + 436 (mach_msg.c:0)
3   libsystem_kernel.dylib … mach_msg + 24 (mach_msg.c:323)
4   CoreFoundation         … __CFRunLoopServiceMachPort + 160 (CFRunLoop.c:2624)
5   CoreFoundation         … __CFRunLoopRun + 1208 (CFRunLoop.c:3007)
6   CoreFoundation         … CFRunLoopRunSpecific + 608 (CFRunLoop.c:3420)
7   GraphicsServices       … GSEventRunModal + 164 (GSEvent.c:2196)
8   UIKitCore              … -[UIApplication _run] + 888 (UIApplication.m:3685)
9   UIKitCore              … UIApplicationMain + 340 (UIApplication.m:5270)
10  App                    … main + 64 (AppDelegate.swift:5)
11  dyld                   … start + 2240 (dyldMain.cpp:1269)

Frame 0 shows that the crashing thread is parked safely within mach_msg2_trap, that is, the run loop is waiting for the system to deliver it events. On iOS it’s basically impossible for a thread to crash with a SIGABRT inside mach_msg2_trap, so something isn’t right with your crash report. And the #1 cause of such problems is… you guessed it… third-party crash reporters.

My advice is that you remove your third-party crash report and see whether a ‘clean’ crash report helps you investigate this.

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

[1] It’s possible for a SIGABRT to be delivered from outside your process. On macOS that’s a theory worth investigating, but I’ve never seen it happen on iOS.

1

Answer 3

MaxDonchenko OP

Jan ’24

Thanks a lot for the super quick response @eskimo!
From your experience, do you think a custom crash reporter is added by Capacitor, Sentry, or something else here? Asking to know where to dig next 🙏

0