Strange app crash from PKPassLibrary passesOfType

Question

Created Jan ’24

Replies 1

Boosts 0

Participants 2

I'm experiencing a strange app crash that I'm having a tough time debugging. It seems to happen when calling PKPassLibrary.passes(of:), but I'm unable to reproduce it. We're using a third party crash reporter, which I know can corrupt crash reports - does that seem to be the case here? The whole report is available here: https://gist.github.com/kylebshr/3ed29dd47ee05f2a5e47993bf986b8f4

0  libsystem_kernel.dylib +0x1174 _mach_msg2_trap
1  libsystem_kernel.dylib +0xf0c  _mach_msg2_internal
2  libsystem_kernel.dylib +0xe24  _mach_msg_overwrite
3  libsystem_kernel.dylib +0xc64  _mach_msg
4  libdispatch.dylib +0x1eefc     __dispatch_mach_send_and_wait_for_reply
5  libdispatch.dylib +0x1f29c     _dispatch_mach_send_with_result_and_wait_for_reply
6  libxpc.dylib +0x106d0          _xpc_connection_send_message_with_reply_sync
7  Foundation +0x37bcc            ___NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY__
8  Foundation +0x202e4            -[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:]
9  CoreFoundation +0x31b58        ____forwarding___
10 CoreFoundation +0x17294c       ___forwarding_prep_0___
11 PassKitCore +0x1c5e94          -[PKPassLibrary _copyPassesOfType:withRetries:]
12 PassKitCore +0x1b0650          -[PKPassLibrary passesOfType:]
13 Mercury +0x3758c               _mh_execute_header
14 Mercury +0x604bcc              main
15 Mercury +0x9e0d34              main
16 Mercury +0x9e0f88              main
17 Mercury +0xa320ec              main
18 Mercury +0x9ea514              main
19 Mercury +0x9eaa58              main
20 Mercury +0x9eaa08              main
21 Mercury +0x9f1650              main
22 Mercury +0x9f16f0              main
23 libdispatch.dylib +0x42fc      __dispatch_client_callout
24 libdispatch.dylib +0x77b4      __dispatch_continuation_pop
25 libdispatch.dylib +0x1b5bc     __dispatch_source_latch_and_call
26 libdispatch.dylib +0x1a18c     __dispatch_source_invoke
27 libdispatch.dylib +0x128a4     __dispatch_main_queue_drain
28 libdispatch.dylib +0x125ac     __dispatch_main_queue_callback_4CF
29 CoreFoundation +0x36f98        ___CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
30 CoreFoundation +0x33ca4        ___CFRunLoopRun
31 CoreFoundation +0x333f4        _CFRunLoopRunSpecific
32 GraphicsServices +0x34f4       _GSEventRunModal
33 UIKitCore +0x22c89c            -[UIApplication _run]
34 UIKitCore +0x22bed8            _UIApplicationMain
35 UIKitCore +0x456594            0x18a42d594 (0x18a42d530 + 100)
36 Mercury +0x1bdff4              main
37 dyld +0x5dc8                   start

Boost

Answer 1

DTS Engineer OP

Apple

Feb ’24

does that seem to be the case here?

It’s hard to say. Looking at the hand report you posted, there’s no obvious sign that your hang detector is messing things up. However, it’s is very easy to create a hang detector that does mess things up.

If your hang report is to be believed, the main thread has got stuck inside a synchronous XPC. To make progress on that, you really need a sysdiagnose log, and the spin dump that it contains.

How often is this being reported? If it’s often enough that your beta testers are likely to be seeing it, you could ask them to try to get you a sysdiagnose log. I have some hints and tips about that in Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem.

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

0