Thanks for the crash report. The thing to note here is that supportsCellularPlan isn’t actually crashing. Consider this:
Termination Reason: FRONTBOARD 2343432205
<RBSTerminateContext| domain:10 code:0x8BADF00D explanation:[application<de.congstar.fraenk>:11234] failed to terminate gracefully after 5.0s
The 0x8BADF00D indicates that your app was killed by the watchdog for being unresponsive. And the end of that lines suggests that the specific event in play was a termination, and that has a short timeout of 5 seconds.
In situations like this there’s two possibilities:
-
You were running code trying to terminate and ran out of time.
-
Something blocked for a long period of time, and that’s why you ran out of time. In this case the obvious candidate is supportsCellularPlan.
Now considered this:
WatchdogCPUStatistics: (
"Elapsed total CPU time (seconds): 3.570 (user 2.240, system 1.330), 11% CPU",
"Elapsed application CPU time (seconds): 0.001, 0% CPU"
) reportType:CrashLog maxTerminationResistance:Interactive>
The watchdog gave you 5 seconds to terminate and you spent 3.57 seconds doing stuff. That’s pretty close to budget, so it’s possible that this really was just you running out of time. But it’s also possible that supportsCellularPlan blocked for some reason, and that’s why you ran out.
You backtrace looks like this:
0 libsystem_kernel.dylib … mach_msg_trap + 8
1 libsystem_kernel.dylib … mach_msg + 76 (mach_msg.c:119)
2 libdispatch.dylib … _dispatch_mach_send_and_wait_for_reply + 540 (mach.c:815)
3 libdispatch.dylib … dispatch_mach_send_with_result_and_wait_for_reply + 60 (mach.c:1973)
4 libxpc.dylib … xpc_connection_send_message_with_reply_sync + 240 (connection.c:974)
5 Foundation … __NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY__ + 16 (NSXPCConnection.m:223)
6 Foundation … -[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:] + 2540 (NSXPCConnection.m:1649)
7 CoreFoundation … ___forwarding___ + 1128 (NSForwarding.m:3618)
8 CoreFoundation … _CF_forwarding_prep_0 + 96
9 CoreTelephony … -[CoreTelephonyClient(CellularPlanManager) supportsPlanProvisioning:carrierDescriptors:smdpUrl:iccidPrefix:] + 240 (CoreTelephonyClient+CellularPlanManager.mm:81)
10 CoreTelephony … -[CTCellularPlanProvisioning supportsCellularPlan] + 548 (CTCellularPlanProvisioning.mm:49)
11 fraenk … closure #1 in closure #1 in EPOnboardingViewController.checkESimSupport() + 72 (EPOnboardingViewController.swift:155)
12 fraenk … thunk for @escaping @callee_guaranteed () -> () + 28 (<compiler-generated>:0)
13 libdispatch.dylib … _dispatch_call_block_and_release + 32 (init.c:1517)
Frames 12…11 is your code being run by Dispatch. Frame 11 is it fetching supportsCellularPlan. The rest of the backtrace indicates that CT is doing a synchronous IPC to its back-end daemon. Again, it’s possible that the daemon is unresponsive, which is why you died this way. Or it could be that CT is just an innocent bystander, and the watchdog just happened to kill the process while it was waiting for a relatively short delay caused by this CT IPC.
How frequent is this crash?
Are you seeing other 0x8BADF00D crash reports with different backtraces?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
