We started to see some crashes in our iOS app a few seconds after launch with the following reason:
Exception Type: EXC_CRASH (SIGILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: SIGNAL 4 Illegal instruction: 4
when calling [NSPersistentContainer loadPersistentStoresWithCompletionHandler:].
I've looked through Understanding the exception types in a crash report page, but couldn't find this type there.
Any ideas what could it be?
Unfortunately I can't attach a crash report, sorry. I always get "This post contains sensitive language. Please revise it in order to continue." no matter what.
SIGILL is a signal Illegal instruction (it's there in the crash).
To me, it looks like there's some issue with your data store. I would debug it and maybe print out the location of your data store, and see whether it's accessible.
I suspect you’re on Intel, in which case SIGILL is most strongly correlated with a trap, that is, some code deliberately crashing because it detected some bad state. See EXC_BREAKPOINT (SIGTRAP) and EXC_BAD_INSTRUCTION (SIGILL).
Unfortunately I can't attach a crash report
Try attaching it to to a reply on this thread. I’ve seen a lot of cases where attaching the crash report to the original post fails but attaching it to a reply works.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Here goes another attempt at attaching a crash report:
the app is running on an iPhone
Oh, interesting.
Here goes another attempt at attaching a crash report:
And that worked. Thanks!
Thread 15 of that crash report indicates that you have a third-party crash reporter installed. I recommend that you remove that. It’s common for third-party crash reporters to disrupt the Apple crash reporter. Implementing Your Own Crash Reporter explains that in gory detail.
Other than on Intel, where it’s used as a trap, SIGILL is quite rare. It typically means you’ve jumped off into Never-Never Land [1]. In that case the crashing thread backtrace typically shows useful results.
In your case, however, the crashing thread backtrace is this:
Thread 0 name:
Thread 0 Crashed:
0 libsystem_kernel.dylib … stat64 + 8 (:-1)
1 CoreFoundation … _CFGetFileProperties + 164 …
There’s no way that the stat64 system call contains illegal instructions, so something else is going wrong. And the most likely cause is your third-party crash reporter.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Apparently that’s an Australian-ism, which I didn’t know of until today.