iOS 18 CoreFoundation crash in __CFRunLoopServiceMachPort (EXC_BREAKPOINT SIGTRAP)

Crash Stacks From APM

What is “APM” in this context?

To help you out here I need to see a crash report. Please post one, using the instructions in Posting a Crash Report.

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

Thanks,h

Additional information: This crash is related to the app going into the background. In some cases, the app crashes immediately when reopened after being in the background for a long time (e.g., 1 day). In other cases, it crashes after being in the background for an extended period.

You’re using a third-party crash reporter and it’s undermining your ability to debug this issue. This is not uncommon. I discuss this in way too much detail in Implementing Your Own Crash Reporter.

My advice is that you remove your third-party crash reporter and then wait for new Apple crash reports to arrive.

To illustrate the sorts of problems I’m talking about here, let me pull apart that second crash report, starting with this:

Exception Type:  EXC_CRASH (SIGSEGV)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Triggered by Thread:  0

This shows that your process crashed due to a memory access exception. That it, it was running some code that accessed an invalid memory location. Let’s look at the backtrace of 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 + 76 (mach_msg.c:201)
2  libsystem_kernel.dylib … mach_msg_overwrite + 428 (mach_msg.c:0)
3  libsystem_kernel.dylib … mach_msg + 24 (mach_msg.c:323)
4  CoreFoundation         … __CFRunLoopServiceMachPort + 160 (CFRunLoop.c:2637)
5  CoreFoundation         … __CFRunLoopRun + 1208 (CFRunLoop.c:3021)
6  CoreFoundation         … CFRunLoopRunSpecific + 572 (CFRunLoop.c:3434)
7  GraphicsServices       … GSEventRunModal + 168 (GSEvent.c:2196)
8  UIKitCore              … -[UIApplication _run] + 816 (UIApplication.m:3845)
9  UIKitCore              … UIApplicationMain + 336 (UIApplication.m:5540)
10 KwaiYDelux             … main + 144 (main.m:17)
11 dyld                   … start + 5964 (dyldMain.cpp:1443)

So the code that accessed the invalid memory is at frame 0, that is, offset 8 into mach_msg2_trap. However, that’s impossible. mach_msg2_trap is a system call, and that specific instruction can’t trigger a memory access exception:

(lldb) disas -a 0x000000018943cc2c
libsystem_kernel.dylib`mach_msg2_trap:
    0x18943cc2c <+0>: mov   x16, #-0x2f ; =-47
    0x18943cc30 <+4>: svc    #0x80
    0x18943cc34 <+8>: ret    

IMPORTANT Due to the way backtracing works, the actual instruction in question is the svc at +4, not the ret at +8 [1].

Deeper in the crash report I see this:

Thread 24 name:
Thread 24:
0 libsystem_kernel.dylib  … mach_msg2_trap + 8 (:-1)
1 libsystem_kernel.dylib  … mach_msg2_internal + 76 (mach_msg.c:201)
2 libsystem_kernel.dylib  … thread_suspend + 108 (thread_actUser.c:1036)
3 KwaiYDelux              … handleExceptions + 128 (KSCrashMonitor_MachException.c:285)
4 libsystem_pthread.dylib … _pthread_start + 136 (pthread.c:931)
5 libsystem_pthread.dylib … thread_start + 8 (:-1)

Frame 3 clearly indicates you have a third-party crash reporter in play. That crash reporter has failed to preserve the Apple crash report, and so now we’re chasing ghosts )-:

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

[1] A ret can’t cause a memory access exception either. If the return address is bogus, you’ll crash trying to fetch the returned-to instruction, not in the ret, and that would result in a very different crash report.