User crash report contains ??? instead of my app's symbols and no binary image base address

Another strange thing is that when dragging the crash report to the Xcode dock icon, the Xcode console logs this error:

User Command: command script import -s lldb.macosx.crashlog
User Command: crashlog --interactive --skip-status --no-parallel-image-loading "~/crash.ips"
Resolved symbols for 0A35BC69-660D-3BC0-8AB4-3FA8D922EECB /usr/lib/libobjc-trampolines.dylib...
Resolved symbols for 79EFE8B6-A212-3E98-B801-C9F2BF18EA68 /usr/lib/dyld...
Traceback (most recent call last):
  File "/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python/lldb/macosx/crashlog.py", line 1444, in __call__
    SymbolicateCrashLogs(debugger, shlex.split(command), result, True)
  File "/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python/lldb/macosx/crashlog.py", line 1855, in SymbolicateCrashLogs
    load_crashlog_in_scripted_process(
  File "/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python/lldb/macosx/crashlog.py", line 1557, in load_crashlog_in_scripted_process
    process.GetScriptedImplementation().set_crashlog(crashlog)
  File "/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python/lldb/macosx/crashlog_scripted_process.py", line 46, in set_crashlog
    self.threads[thread.index] = CrashLogScriptedThread(self, None, thread)
  File "/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python/lldb/macosx/crashlog_scripted_process.py", line 171, in __init__
    super().__init__(process, args)
  File "/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python/lldb/plugins/scripted_process.py", line 271, in __init__
    self.get_register_info()
  File "/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python/lldb/plugins/scripted_process.py", line 365, in get_register_info
    raise ValueError("Unknown architecture", self.originating_process.arch)
ValueError: ('Unknown architecture', 'x86_64h')

Consider this:

Exception Type:    EXC_BAD_ACCESS (SIGBUS)
Exception Subtype: KERN_MEMORY_ERROR at 0x000000010844eb40

and this:

Thread 0 crashed with X86 Thread State (64-bit):
  …
  rip: 0x000000010844eb40  …

(In Intel, RIP is the PC register.)

Your program has crashed to an unmapped memory exception and the crashing address is the PC. That is, the program has jumped to a bad address. That’s why you get this:

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   ???                           	       0x10844eb40 ???

because there is no code mapped at that location.

Notably, let’s look at more of that backtrace:

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0 ???                0x10844eb40 ???
1 CoreFoundation  0x7ff80f155518 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 137
2 CoreFoundation  0x7ff80f1b864e ___CFXRegistrationPost_block_invoke + 88
3 CoreFoundation  0x7ff80f1b85a2 _CFXRegistrationPost + 515
4 CoreFoundation  0x7ff80f134dd6 _CFXNotificationPost + 763
5 Foundation      0x7ff810e22752 -[NSNotificationCenter postNotificationName:object:userInfo:] + 82
6 AppKit          0x7ff8130ca2e1 __postVolumeNotification_block_invoke + 64

Frame 6 is AppKit posting a volume notification. Frames 5 through 1 are notification infrastructure. Frame 0 is your crash.

The most likely causes of this are:

• You’ve registered for a notification and then the underlying object has been deallocated.
• Something has corrupted memory.

If you’re using volume notifications then I recommend that you focus your efforts there. Also engage the standard memory debugging tools to see if you can make this more reproducible. And do this all while generating volume notifications, for example, mounting and unmounting volumes.

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

Thanks for your explanations. Is the unmapped memory exception also the reason why the binary image address for my app is 0x0 - 0xffffffffffffffff?

I can confirm that the app registers for volume notifications using

let workspaceNotificationCenter = NSWorkspace.shared.notificationCenter
workspaceNotificationCenter.addObserver(self, selector: #selector(didWake(_:)), name: NSWorkspace.didWakeNotification, object: nil)
workspaceNotificationCenter.addObserver(self, selector: #selector(volumeDidMount(_:)), name: NSWorkspace.didMountNotification, object: nil)
workspaceNotificationCenter.addObserver(self, selector: #selector(volumeDidRename(_:)), name: NSWorkspace.didRenameVolumeNotification, object: nil)
workspaceNotificationCenter.addObserver(self, selector: #selector(volumeWillUnmount(_:)), name: NSWorkspace.willUnmountNotification, object: nil)
workspaceNotificationCenter.addObserver(self, selector: #selector(volumeDidUnmount(_:)), name: NSWorkspace.didUnmountNotification, object: nil)

The object that registers them also unregisters them in its deinit:

NSWorkspace.shared.notificationCenter.removeObserver(self)

Admittedly, I'm not sure if the unregistration works or if the deinit is prevented from being called by the notification center retaining the observer. I mainly added that code for "completeness", but in reality the observer is a let property of the app delegate, so it lives as long as the app lives.

Besides, the unregistration seems to be superfluous according to the documentation:

If your app targets iOS 9.0 and later or macOS 10.11 and later, you do not need to unregister an observer that you created with this function. If you forget or are unable to remove an observer, the system cleans up the next time it would have posted to it.

I also wasn't able to reproduce the crash with the tools you suggested, and I don't think I have seen this kind of crash before (my app has been on the App Store for many years).

Does this rule out the first most likely cause and shifts "Something has corrupted memory" from suspect number two to number one?