Hello, we have encountered a large number of __CFRunLoopServiceMachPort.cold crashes on iOS 26. These crashes frequently occur when the app transitions from the background to the foreground or is launched after sitting idle for a period of time. Despite extensive analysis, we have been unable to find a solution. Currently, the crash data indicates that this issue is specific to iOS 26. We would greatly appreciate your assistance. Thank you very much!
Hardware Model: iPhone18,1 OS Version: iPhone OS 26.5.2 (23F84) Release Type: User Baseband Version: 1.60.02
Crash Reporter Key: fda96a4036dcb83e124660e11b654c9484b81dae Incident Identifier: EF18C4DD-7624-42D0-BA72-F17BBC263B16
Time Awake Since Boot: 2900000 seconds
Triggered by Thread: 0, Dispatch Queue: com.apple.main-thread
Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x00000001917d316c
Termination Reason: Namespace SIGNAL, Code 5, Trace/BPT trap: 5 Terminating Process: exc handler [82210]
Application Specific Information: (ipc/rcv) invalid name
Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 CoreFoundation 0x1917d316c __CFRunLoopServiceMachPort.cold.1 + 64 1 CoreFoundation 0x19168a444 __CFRunLoopServiceMachPort + 416 2 CoreFoundation 0x191654310 __CFRunLoopRun + 1188 3 CoreFoundation 0x19165354c _CFRunLoopRunSpecificWithOptions + 532 4 GraphicsServices 0x236df7498 GSEventRunModal + 120 5 UIKitCore 0x19734c244 -[UIApplication _run] + 796 6 UIKitCore 0x1972b7158 UIApplicationMain + 332 7 KMMVideo 0x1047fe24c 0x104304000 + 5218892 8 dyld 0x18e261c1c start + 6928
Thread 1 name: transmit_hls_7683_193735 Thread 1: 0 libsystem_kernel.dylib 0x2407da5e8 __psynch_cvwait + 8 1 libsystem_pthread.dylib 0x1f0852b48 _pthread_cond_wait + 980 2 libc++.1.dylib 0x1a0d5dbcc std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 32 3 iOSPlayer 0x118cd6114 a_task_runner::worker() + 116 4 iOSPlayer 0x118cd5650 a_task_runner::work_thread() + 196 5 iOSPlayer 0x118cd654c void* std::__1::__thread_proxy[abi:ne200100]<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, void (a_task_runner::)(), a_task_runner>>(void*) + 72 6 libsystem_pthread.dylib 0x1f0854438 _pthread_start + 136 7 libsystem_pthread.dylib 0x1f08508cc thread_start + 8
Thread 2: 0 libsystem_kernel.dylib 0x2407d9ed8 read + 8 1 XLTranscodeKit 0x115bb5f4c runtime.read_trampoline.abi0 + 28
Thread 3:
Thread 4: 0 libsystem_kernel.dylib 0x2407da5e8 __psynch_cvwait + 8 1 libsystem_pthread.dylib 0x1f0852b48 _pthread_cond_wait + 980 2 XLTranscodeKit 0x115bb6648 runtime.pthread_cond_wait_trampoline.abi0 + 24 3 XLTranscodeKit 0x115bb4fb8 runtime.asmcgocall.abi0 + 200 4 ??? 0xd65f03c0 ???
Thread 5: 0 XLTranscodeKit 0x115b3eb68 */bytealg.IndexByteString + 40 1 XLTranscodeKit 0x115b966b8 runtime.findnull + 104
Thread 6: 0 libsystem_kernel.dylib 0x2407db8dc kevent + 8 1 XLTranscodeKit 0x115bb6398 runtime.kevent_trampoline.abi0 + 40
Thread 7: 0 libsystem_kernel.dylib 0x2407da5e8 __psynch_cvwait + 8 1 libsystem_pthread.dylib 0x1f0852b48 _pthread_cond_wait + 980 2 XLTranscodeKit 0x115bb6648 runtime.pthread_cond_wait_trampoline.abi0 + 24 3 XLTranscodeKit 0x115bb4fb8 runtime.asmcgocall.abi0 + 200 4 ??? 0xd65f03c0 ???
I have provided the complete crash JSON file.
No you haven’t. That’s a human reasonable crash report (.crash) and I was looking for JSON one (.ips). It’s also truncated )-:
However, it’ll probably do.
Your crashing thread backtrace looks like this:
Thread 0 Crashed:
0 CoreFoundation … __CFRunLoopServiceMachPort.cold.1 + 64
1 CoreFoundation … __CFRunLoopServiceMachPort + 416
2 CoreFoundation … __CFRunLoopRun + 1188
3 CoreFoundation … _CFRunLoopRunSpecificWithOptions + 532
4 GraphicsServices … GSEventRunModal + 120
5 UIKitCore … -[UIApplication _run] + 796
6 UIKitCore … UIApplicationMain + 332
7 KMMVideo … 0x104304000 + 5218892
8 dyld … start + 6928
Frame 0 and the crash type itself (EXC_BREAKPOINT) strongly suggest that you’ve hit this line. That is, CFRunLoop got back an unexpected error from Mach messaging and trapped.
The crash report also includes this:
Application Specific Information:
(ipc/rcv) invalid name
That string corresponds to KERN_INVALID_NAME, described in <mach/kern_return.h> as “The name doesn't denote a right in the task.” It seems that the run loop is working with a Mach port name that was either never correct or has been invalidated in some way.
The fact that this is the main thread, and hence the main thread’s run loop, complicates things. Lots of different run loop sources get scheduled on the main thread, and it’s hard to map back from a crash report to the specific source in question.
And even if you could do that, there’s no guarantee that the source is at fault. It’s not uncommon to see incorrect code invalidate a Mach port name incorrectly, resulting in some other, unrelated code getting this error (it’s kinda like erroneously closing a file descriptor).
The other concern here is that you have a third-party crash reporter in play (look at thread 28) and those are not to be trusted. Specifically:
- A third-party crash reporter can corrupt the Apple crash reports, meaning that the analysis above might be based on false information.
- Third-party crash reporters often use Mach messaging, which could result in an error like this.
So, my specific advice is that you remove your third-party crash reporter [1] and wait for more crash reports to come in. There’s a small possibility that they won’t, in which case you know what the problem was. It’s more likely that they will, but in that case you will at least have a set of crash reports you can trust.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Or switch one based on the new CrashReportExtension framework.