Hi,
I have received the following report after app termination. I have researched online but cannot determine the root cause. Any tips or ideas would help please.
Could it be Location Services, UserNotification Services, or Network Requests?
Thank you, Brendan
Translated Report (Full Report Below)
Incident Identifier: 6CD59A17-15B1-4F4E-AE84-0286F22893A4 CrashReporter Key: 3d12FB7359053239708afd24c7eed0267a9cc601 Hardware Model: iPhone13,3 Process: AnchorNet3 [5605] Path: /private/var/containers/Bundle/Application/5EA7F893-D562-45B8-8995-5EAB15F85A7E/AnchorNet3.app/AnchorNet3 Identifier: com.sailsecrets.AnchorNet3 Version: 3.17 (3.17) Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: com.sailsecrets.AnchorNet3 [1443]
Date/Time: 2025-02-06 00:12:03.6136 +0100 Launch Time: 2025-02-05 22:11:19.4220 +0100 OS Version: iPhone OS 18.2 (22C5131e) Release Type: Beta Baseband Version: 5.20.03 Report Version: 104
Exception Type: EXC_RESOURCE (SIGKILL) Exception Codes: 0x0000000000020000, 0x0000000000000000 Termination Reason: PORT_SPACE 14123288431434006528 (Limit 131072 ports) Exceeded system-wide per-process Port Limit
Triggered by Thread: 3
Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0: 0 libsystem_kernel.dylib 0x1e27414e4 kevent_id + 8 1 libdispatch.dylib 0x198f51b40 _dispatch_kq_poll + 228 2 libdispatch.dylib 0x198f51080 _dispatch_event_loop_poke + 340 3 QuartzCore 0x192d4631c CA::Context::commit_transaction(CA::Transaction*, double, double*) + 17164 4 QuartzCore 0x192cb8d58 CA::Transaction::commit() + 648 5 QuartzCore 0x192cb8764 CA::Transaction::flush_as_runloop_observer(bool) + 88 6 UIKitCore 0x193a3fd14 _UIApplicationFlushCATransaction + 52 7 UIKitCore 0x193a3d1e0 __setupUpdateSequence_block_invoke_2 + 332 8 UIKitCore 0x193a3d054 UIUpdateSequenceRun + 84 9 UIKitCore 0x193a3f984 schedulerStepScheduledMainSection + 172 10 UIKitCore 0x193a3d5a0 runloopSourceCallback + 92 11 CoreFoundation 0x1911f1f3c CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 28 12 CoreFoundation 0x1911f1ed0 __CFRunLoopDoSource0 + 176 13 CoreFoundation 0x1911f4b30 __CFRunLoopDoSources0 + 244 14 CoreFoundation 0x1911f3d2c __CFRunLoopRun + 840 15 CoreFoundation 0x191246274 CFRunLoopRunSpecific + 588 16 GraphicsServices 0x1de34d4c0 GSEventRunModal + 164 17 UIKitCore 0x193d8f480 -[UIApplication run] + 816 18 UIKitCore 0x1939b5410 UIApplicationMain + 340 19 SwiftUI 0x195b43e30 closure #1 in KitRendererCommon(:) + 168 20 SwiftUI 0x195b43d60 runApp<A>(:) + 100 21 SwiftUI 0x195b43c44 static App.main() + 180 22 AnchorNet3.debug.dylib 0x1025e97bc static MainApp.$main() + 40 23 AnchorNet3.debug.dylib 0x1025eaacc __debug_main_executable_dylib_entry_point + 12 24 dyld 0x1b7352de8 start + 2724
Thread 1 name: com.apple.CoreMotion.MotionThread Thread 1: 0 libsystem_kernel.dylib 0x1e2741788 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x1e2744e98 mach_msg2_internal + 80 2 libsystem_kernel.dylib 0x1e2744db0 mach_msg_overwrite + 424 3 libsystem_kernel.dylib 0x1e2744bfc mach_msg + 24 4 CoreFoundation 0x1911f47f4 __CFRunLoopServiceMachPort + 160 5 CoreFoundation 0x1911f3ea0 __CFRunLoopRun + 1212 6 CoreFoundation 0x191246274 CFRunLoopRunSpecific + 588 7 CoreFoundation 0x191259814 CFRunLoopRun + 64 8 CoreMotion 0x19e89cc5c 0x19e88d000 + 64604 9 libsystem_pthread.dylib 0x21bcfb7d0 _pthread_start + 136 10 libsystem_pthread.dylib 0x21bcfb480 thread_start + 8
Thread 2 name: com.apple.uikit.eventfetch-thread Thread 2: 0 libsystem_kernel.dylib 0x1e2741788 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x1e2744e98 mach_msg2_internal + 80 2 libsystem_kernel.dylib 0x1e2744db0 mach_msg_overwrite + 424 3 libsystem_kernel.dylib 0x1e2744bfc mach_msg + 24 4 CoreFoundation 0x1911f47f4 __CFRunLoopServiceMachPort + 160 5 CoreFoundation 0x1911f3ea0 __CFRunLoopRun + 1212 6 CoreFoundation 0x191246274 CFRunLoopRunSpecific + 588 7 Foundation 0x18fdc8338 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212 8 Foundation 0x18ff24e24 -[NSRunLoop(NSRunLoop) runUntilDate:] + 64 9 UIKitCore 0x193e22a74 -[UIEventFetcher threadMain] + 420 10 Foundation 0x18feb4194 NSThread__start + 724 11 libsystem_pthread.dylib 0x21bcfb7d0 _pthread_start + 136 12 libsystem_pthread.dylib 0x21bcfb480 thread_start + 8
Thread 3 name: com.apple.SwiftUI.AsyncRenderer Thread 3 Crashed: 0 libsystem_kernel.dylib 0x1e274162c _kernelrpc_mach_port_allocate_trap + 8 1 libsystem_kernel.dylib 0x1e2748478 mach_port_allocate + 36 2 QuartzCore 0x192d4552c CA::Context::commit_transaction(CA::Transaction*, double, double*) + 13596 3 QuartzCore 0x192cb8d58 CA::Transaction::commit() + 648 4 QuartzCore 0x192cb8764 CA::Transaction::flush_as_runloop_observer(bool) + 88 5 CoreFoundation 0x19119f894 CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION + 36 6 CoreFoundation 0x19119f3e8 __CFRunLoopDoObservers + 552 7 CoreFoundation 0x1912462c0 CFRunLoopRunSpecific + 664 8 Foundation 0x18fdc8338 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212 9 Foundation 0x18fdc4500 -[NSRunLoop(NSRunLoop) run] + 64 10 SwiftUI 0x195c276d8 specialized static DisplayLink.asyncThread(arg:) + 792 11 SwiftUI 0x195c273a8 @objc static DisplayLink.asyncThread(arg:) + 72
<<POST SIZE LIMIT>>
First, lemme define two terms, albeit vaguely:
-
A light object is something that you can create and destroy willy-nilly.
-
A heavy object owns a resource and thus it makes sense to create one instance and share it (or maybe a small number of instances).
It’s hard to know from the outside whether a particular object is heavy or ‘light’. Sometimes that information is covered in the documentation — a good example of this is URLSession
, where we go out of our way to document that it’s heavy — but in other cases you just have to infer it from the examples in the docs, the published sample code, and so on.
This thread suggests that CMAltimeter
is heavier than it looks, and thus it makes sense to maintain a small number of instances.
However, there’s something else going on here. Even with a heavy object, creating and destroying the object a bunch of times shouldn’t leak Mach ports. The object should clean up after itself. However, I played around this myself and encountered something weird. Consider this code:
func test() {
let before = machPortCount()
autoreleasepool {
for _ in 0..<100 {
_ = CMAltimeter()
}
}
let after = machPortCount()
print(before, after)
}
where machPortCount()
is a function I wrote that returns the number of Mach ports allocated by this process [1]. I then wired it up to a button and ran the app on a device (iOS 18.3.1). Every time I tapped the button, the count goes up by about 200!
122 331
335 548
550 748
750 949
912 1123
That’s problematic to say the least.
So, given the above, my advice is:
-
File a bug against
CMAltimeter
. Allocating and deallocating the object shouldn’t leak Mach ports [2]. When you’re done, please post the bug number here so that I can add my analysis to it. -
The workaround is to reduce the number of
CMAltimeter
objects you allocate to the bare minimum.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Technically, it’s the number of port names in this task’s namespace. I implemented this function using Mach APIs. I’m not gonna share the code because it’s too large, but if you want a taste of how this works you can check out the (ancient) MachPortDump sample code.
[2] I think it’s actually leaking objects, and those objects own the Mach ports, but that’s a distinction that doesn’t make a difference. You’re gonna run out of Mach ports way earlier than you run out of memory.