Xcode downloads client crash report but the stacktraces don't contain any of my app's symbols

Your app has an uncaught C++ exception. Due to system limitations, the backtrace for pure C++ exceptions is not recorded into the crash report like it is for Objective-C exceptions (see the Note in our documentation).

While these are fairly course data points, perhaps they are helpful to help you narrow things down a little bit:

• The exception was thrown on the main thread, as that's where the standard system symbols for handling exceptions appear in this crash.
• The invocation site originates with a call to something being called via the main dispatch queue (see frame 8 of the main thread), so that might be something like a callback from another thread you are dispatching to the main thread in your code.

With those items plus the data point about a C++ exception, hopefully you have at least something to start triangulating the crash from in your code.

— Ed Ford,  DTS Engineer

Thanks. Does that mean that C++ code caused the crash? My app is written in pure Swift with a bridging header that only defines these constants needed for accessing the results of getattrlistbulk on iOS:

enum vtype    { VNON, VREG, VDIR, VBLK, VCHR, VLNK, VSOCK, VFIFO, VBAD, VSTR,
              VCPLX };

When causing a crash on the main thread with the following code

@main
class AppDelegate: NSObject, NSApplicationDelegate {

    func applicationDidFinishLaunching(_ aNotification: Notification) {
        // Insert code here to initialize your application
        DispatchQueue.main.async {
            fatalError()
        }
    }

}

I get this stacktrace in the crash report:

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   libswiftCore.dylib            	       0x1a06b906c _assertionFailure(_:_:file:line:flags:) + 592
1   problem2                      	       0x100d1a8e4 closure #1 in AppDelegate.applicationDidFinishLaunching(_:) + 68 (AppDelegate.swift:19)
2   problem2                      	       0x100d1a904 thunk for @escaping @callee_guaranteed () -> () + 28
3   libdispatch.dylib             	       0x1907fb750 _dispatch_call_block_and_release + 32
4   libdispatch.dylib             	       0x1907fd3e8 _dispatch_client_callout + 20
5   libdispatch.dylib             	       0x19080bbb8 _dispatch_main_queue_drain + 988
6   libdispatch.dylib             	       0x19080b7cc _dispatch_main_queue_callback_4CF + 44
7   CoreFoundation                	       0x190acead4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16
8   CoreFoundation                	       0x190a8c258 __CFRunLoopRun + 1996
9   CoreFoundation                	       0x190a8b434 CFRunLoopRunSpecific + 608
10  HIToolbox                     	       0x19b23519c RunCurrentEventLoopInMode + 292
11  HIToolbox                     	       0x19b234e2c ReceiveNextEventCommon + 220
12  HIToolbox                     	       0x19b234d30 _BlockUntilNextEventMatchingListInModeWithFilter + 76
13  AppKit                        	       0x1942eacc8 _DPSNextEvent + 660
14  AppKit                        	       0x194ae14d0 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 700
15  AppKit                        	       0x1942ddffc -[NSApplication run] + 476
16  AppKit                        	       0x1942b5240 NSApplicationMain + 880
17  problem2                      	       0x100d1aacc specialized static NSApplicationDelegate.main() + 24 [inlined]
18  problem2                      	       0x100d1aacc static AppDelegate.$main() + 24 (<compiler-generated>:10) [inlined]
19  problem2                      	       0x100d1aacc main + 36
20  dyld                          	       0x190623154 start + 2476

Or where you hinting at something different?

The crash signature varies based on why the app is terminated. Your example with fatalError is one such path and the type of stack for that. Here's a different test with C++ using the basic iOS app template in Xcode:

#include <stdexcept>

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    
    throw std::runtime_error("Something went wrong");
}


@end

That produces this crash stack:

Thread 0 name:   Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libsystem_kernel.dylib        	       0x1f1b89254 __pthread_kill + 8
1   libsystem_pthread.dylib       	       0x228cf1ef8 pthread_kill + 267
2   libsystem_c.dylib             	       0x1a915eb6c __abort + 135
3   libsystem_c.dylib             	       0x1a915eae4 abort + 139
4   libc++abi.dylib               	       0x228c155b8 abort_message + 131
5   libc++abi.dylib               	       0x228c03b90 demangling_terminate_handler() + 319
6   libobjc.A.dylib               	       0x19e2d102c _objc_terminate() + 159
7   libc++abi.dylib               	       0x228c1487c std::__terminate(void (*)()) + 15
8   libc++abi.dylib               	       0x228c14820 std::terminate() + 107
9   libdispatch.dylib             	       0x1054fa730 _dispatch_client_callout + 40

Notice that's identical to your crash report in the top frames, and why I was able to identify the type of crash you have.

Contrast that to an Objective-C exception (generated here by over-indexing an array):

- (void)viewDidLoad {
    [super viewDidLoad];
    
    NSArray *array = [NSArray array];
    id value = array[42];
}

That produces the exact same crash stack on Thread 0 as the C++ example. However, the important difference is that it has an additional stack trace called the exception backtrace:

Last Exception Backtrace:
0   CoreFoundation                	       0x1a0fb711c __exceptionPreprocess + 164
1   libobjc.A.dylib               	       0x19e2b6698 objc_exception_throw + 75
2   CoreFoundation                	       0x1a1052b44 -[__NSArray0 objectAtIndex:] + 243
3   CPPExample                    	       0x10004c064 -[ViewController viewDidLoad] + 100

That backtrace points right to what happened to generate the exception. That extra information is what a crash due to an uncaught C++ exception doesn't give you due to the system limitations I called out earlier, which is why identifying the source of a C++ exception crash is so much harder than others.

I'm not deeply familiar with the corner of the system around getattrlistbulk to know what could go wrong around that, though that underlying implementation is in C. I'd suggest that you write a smaller tester app with the same code and see what happens in that circumstance. However, any C++ code running within your process could cause the above, including any C++ implementation within Apple's own frameworks. Having one of those throw a C++ exception is pretty rare, so that's an unlikely source of the problem here, but also not one that can be completely discounted either.

— Ed Ford,  DTS Engineer

any C++ code running within your process could cause the above

Do you mean that such code would have to be in its own .cpp file, or would it be sufficient to call it from a .swift file? Apart from the bridging header, my project only contains Swift files. This crash only seems to be happening to a couple users and it never happened to me, so I don't think I would be luckier trying to reproduce it on a smaller tester app. I guess I'll never find out unless macOS or Swift (I'm not sure which one is responsible here) shows more meaningful exceptions.

Any C++ code that is running in your process could be involved — it would be in one of the binaries listed in the Binary Images section of the crash report. That contains your app binary, as well as some of Apple's frameworks.

One additional thing I noticed as I look at the details here closer, is the app this for macOS or iOS? The crash report you shared is from macOS. You mention AppKit above, but also iOS, so I'm unclear on what your app's target platform is. I mention that in case you have an iOS app running on an Apple silicon Mac, and the crash from these users is only when your iOS app runs on a Mac.

— Ed Ford,  DTS Engineer

You mention AppKit above, but also iOS, so I'm unclear on what your app's target platform is.

Sorry for the confusion. It's a macOS app. I just thought the contents of the bridging header could be meaningful, and I wanted to explain why I'm redeclaring enum vtype even if it's available on macOS (it's because it's not available on iOS, even though getattrlistbulk is, so in order to have the macOS and iOS versions as similar as possible I declare that for both targets).