Xcode doesn't symbolicate system frameworks in crash log

See the following excerpt of a crash log from a release build of my app:
Code Block language
Hardware Model: iPhone11,8
Process: Pupl [45462]
Path: /private/var/containers/Bundle/Application/3D8B69C4-8AE5-40E7-BBDF-93CC12D79E1C/Pupl.app/Pupl
Identifier: com.kevinolmats.Pupl
Version: 285 (1.0.1)
AppStoreTools: 12A7402a
AppVariant: 1:iPhone11,8:14
Code Type: ARM-64 (Native)
Role: Foreground
Parent Process: launchd [1]
Coalition: com.kevinolmats.Pupl [2248]
Date/Time: 2020-10-25 13:38:09.3546 -0700
Launch Time: 2020-10-25 13:33:01.8074 -0700
OS Version: iPhone OS 14.0.1 (18A393)
Release Type: User
Baseband Version: 3.00.01
Report Version: 104
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Triggered by Thread: 0
Application Specific Information:
abort() called
Last Exception Backtrace:
0 CoreFoundation 0x1884d65ac 0x1883b5000 + 1185196
1 libobjc.A.dylib 0x19c55042c 0x19c546000 + 42028
2 CoreData 0x18e58a648 0x18e460000 + 1222216
3 CoreData 0x18e58f6f4 0x18e460000 + 1242868
4 Pupl 0x100a56cac specialized WeightCategoryEditorViewModel.init(course:color:context:) + 339116 (WeightCategoryEditorViewModel.swift:30)
5 Pupl 0x100a4d7a0 closure #1 in closure #1 in closure #1 in CourseEditorWeightCategoryView.body.getter + 300960 (CourseEditorViewModel.swift:0)
6 SwiftUI 0x18ee430b0 0x18e864000 + 6156464
7 SwiftUI 0x18ed4b9c4 0x18e864000 + 5142980
8 SwiftUI 0x18edd0e90 0x18e864000 + 5688976
9 SwiftUI 0x18ee6b3f8 0x18e864000 + 6321144
10 SwiftUI 0x18ee6b6e4 0x18e864000 + 6321892
11 UIKitCore 0x18aff60d0 0x18a273000 + 14168272
12 UIKitCore 0x18aff5c8c 0x18a273000 + 14167180
13 UIKitCore 0x18aff6438 0x18a273000 + 14169144
14 UIKitCore 0x18b2bb544 0x18a273000 + 17073476
15 UIKitCore 0x18ae00400 0x18a273000 + 12112896
16 UIKitCore 0x18adef1bc 0x18a273000 + 12042684
17 UIKitCore 0x18ae22648 0x18a273000 + 12252744
18 CoreFoundation 0x188452444 0x1883b5000 + 644164
19 CoreFoundation 0x18844c858 0x1883b5000 + 620632
20 CoreFoundation 0x18844ce08 0x1883b5000 + 622088
21 CoreFoundation 0x18844c4bc 0x1883b5000 + 619708
22 GraphicsServices 0x19eed1820 0x19eece000 + 14368
23 UIKitCore 0x18adf0734 0x18a273000 + 12048180
24 UIKitCore 0x18adf5e10 0x18a273000 + 12070416
25 SwiftUI 0x18f1ad32c 0x18e864000 + 9737004
26 SwiftUI 0x18f1ad2b8 0x18e864000 + 9736888
27 SwiftUI 0x18ed26b08 0x18e864000 + 4991752
28 Pupl 0x100a1311c main + 61724 (Assignment.swift:0)
29 libdyld.dylib 0x188113e60 0x188113000 + 3680

The problem is, after I symbolicate in Xcode using the Devices window, it only symbolicates calls from my app (Pupl), not any of the system frameworks. Any ideas as to how I can fix this?
Answered by DTS Engineer in 642879022

Here's the full report

Thanks. Let’s work through this. To start, we confirm the CPU type and iOS version:

Code Block
Code Type: ARM-64 (Native)
OS Version: iPhone OS 14.0.1 (18A393)


Now consider this:

Code Block
% cd ~/Library/Developer/Xcode/iOS\ DeviceSupport
% ls | cat
14.0 (18A373) arm64e
14.0 (18A5301v) arm64e
14.0 (18A5351d) arm64e
14.0 (18A5357e) arm64e
14.0 (18A5369b) arm64e
14.0 (18A5373a) arm64e
14.1 (18A8395) arm64e
14.2 (18B5061e) arm64e
14.2 (18B5072f) arm64e


This is a list of all the devices I’ve attached to my Mac and for which Xcode has collected symbols. There’s a bunch of iOS 14.0 beta releases in there (these start with 18A5) but I also have the iOS 14.0 GM release, 18A373. That’s really close to iOS 14.0.1, so we’re going to work with that.

Now let’s consider frame 3 from the Last Exception Backtrace section, which is an example of what we want to symbolicate:

Code Block
3 CoreData 0x18e58f6f4 0x18e460000 + 1242868


The crash is at address 0x18e58f6f4 which is 1242868 bytes from the start of the CoreData framework, 0x18e460000. In the crash report we can find the CoreData framework in the Binary Images section:

Code Block
0x18e460000 - 0x18e7d1fff CoreData arm64e <e6bbd2ec59f6316a9368b53ba3da38ae> /System/…


This says:
  • The framework was loaded at 0x18e460000 and extends to 0x18e7d1fff.

  • Its name is CoreData.

  • It was compiled for arm64e (a more secure variant of arm64 that we use in all our system frameworks).

  • Its binary UUID is e6bbd2ec59f6316a9368b53ba3da38ae.

  • Its path is, well, obvious, so I elided it (-: The path is often relevant on macOS where frameworks can be loaded from all sorts of places.

Now let’s check out the CoreData symbols in iOS DeviceSupport for 14.0 (18A373):

Code Block
% dwarfdump --uuid 14.0\ \(18A373\)\ arm64e/Symbols/System/Library/Frameworks/CoreData.framework/CoreData
UUID: E6BBD2EC-59F6-316A-9368-B53BA3DA38AE (arm64e) 14.0 (18A373) arm64e/Symbols/System/Library/Frameworks/CoreData.framework/CoreData


Interesting. The binary UUID matches our crash report, so we’re not guessing here: Our symbolication results will be precise. It’s time to go for it:

Code Block
% atos \
-o 14.0\ \(18A373\)\ arm64e/Symbols/System/Library/Frameworks/CoreData.framework/CoreData \
-l 0x18e460000 \
0x18e58f6f4
_sharedIMPL_setvfk_core (in CoreData) + 192


Let’s break that down:
  • atos is a tool that’ll map addresses to symbols. See its man page for detailed info on how to use it.

  • The -o line tells atos what image to look at.

  • -l 0x18e460000 specifies the load address for that image.

  • 0x18e58f6f4 is the address to symbolicate.

The tool then outputs the symbol, in this case _sharedIMPL_setvfk_core, and the offset from the start of that symbol, 192.

You should repeat this process for frame 2 of your backtrace.

Note There’s no point doing it for frames 1 through 0 because the presence of the Last Exception Backtrace section makes it clear that these are objc_exception_throw and __exceptionPreprocess respectively.



As to what this error actually means, something has gone wrong in a CoreData managed object setter. This isn’t really my field, so I don’t have any ready answers for you. Once you’ve symbolicated frames 4 through 2 you can start a new thread, requesting help from CoreData experts by tagging it with CoreData.

Share and Enjoy

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

The problem is, after I symbolicate in Xcode using the Devices window,
it only symbolicates calls from my app (Pupl), not any of the system
frameworks.

This is explained in the Acquire Device Symbol Information section of Adding Identifiable Symbol Names to a Crash Report.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Thanks! But what can I do if I don't have a device running that particular version of iOS? Am I out of luck?

But what can I do if I don't have a device running that particular
version of iOS? Am I out of luck?

Yeah, that makes it tricky. If you have a device that’s close to the one from the crash report (same CPU architecture, close OS version) you can try manually symbolicating based on that. For example, this crash report is from iOS 14.0.1 and the symbols there are likely to be very close to that of iOS 14.0.

If you post the full crash report, I can walk you through that process.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Thanks for your help! Here's the full report:



Accepted Answer

Here's the full report

Thanks. Let’s work through this. To start, we confirm the CPU type and iOS version:

Code Block
Code Type: ARM-64 (Native)
OS Version: iPhone OS 14.0.1 (18A393)


Now consider this:

Code Block
% cd ~/Library/Developer/Xcode/iOS\ DeviceSupport
% ls | cat
14.0 (18A373) arm64e
14.0 (18A5301v) arm64e
14.0 (18A5351d) arm64e
14.0 (18A5357e) arm64e
14.0 (18A5369b) arm64e
14.0 (18A5373a) arm64e
14.1 (18A8395) arm64e
14.2 (18B5061e) arm64e
14.2 (18B5072f) arm64e


This is a list of all the devices I’ve attached to my Mac and for which Xcode has collected symbols. There’s a bunch of iOS 14.0 beta releases in there (these start with 18A5) but I also have the iOS 14.0 GM release, 18A373. That’s really close to iOS 14.0.1, so we’re going to work with that.

Now let’s consider frame 3 from the Last Exception Backtrace section, which is an example of what we want to symbolicate:

Code Block
3 CoreData 0x18e58f6f4 0x18e460000 + 1242868


The crash is at address 0x18e58f6f4 which is 1242868 bytes from the start of the CoreData framework, 0x18e460000. In the crash report we can find the CoreData framework in the Binary Images section:

Code Block
0x18e460000 - 0x18e7d1fff CoreData arm64e <e6bbd2ec59f6316a9368b53ba3da38ae> /System/…


This says:
  • The framework was loaded at 0x18e460000 and extends to 0x18e7d1fff.

  • Its name is CoreData.

  • It was compiled for arm64e (a more secure variant of arm64 that we use in all our system frameworks).

  • Its binary UUID is e6bbd2ec59f6316a9368b53ba3da38ae.

  • Its path is, well, obvious, so I elided it (-: The path is often relevant on macOS where frameworks can be loaded from all sorts of places.

Now let’s check out the CoreData symbols in iOS DeviceSupport for 14.0 (18A373):

Code Block
% dwarfdump --uuid 14.0\ \(18A373\)\ arm64e/Symbols/System/Library/Frameworks/CoreData.framework/CoreData
UUID: E6BBD2EC-59F6-316A-9368-B53BA3DA38AE (arm64e) 14.0 (18A373) arm64e/Symbols/System/Library/Frameworks/CoreData.framework/CoreData


Interesting. The binary UUID matches our crash report, so we’re not guessing here: Our symbolication results will be precise. It’s time to go for it:

Code Block
% atos \
-o 14.0\ \(18A373\)\ arm64e/Symbols/System/Library/Frameworks/CoreData.framework/CoreData \
-l 0x18e460000 \
0x18e58f6f4
_sharedIMPL_setvfk_core (in CoreData) + 192


Let’s break that down:
  • atos is a tool that’ll map addresses to symbols. See its man page for detailed info on how to use it.

  • The -o line tells atos what image to look at.

  • -l 0x18e460000 specifies the load address for that image.

  • 0x18e58f6f4 is the address to symbolicate.

The tool then outputs the symbol, in this case _sharedIMPL_setvfk_core, and the offset from the start of that symbol, 192.

You should repeat this process for frame 2 of your backtrace.

Note There’s no point doing it for frames 1 through 0 because the presence of the Last Exception Backtrace section makes it clear that these are objc_exception_throw and __exceptionPreprocess respectively.



As to what this error actually means, something has gone wrong in a CoreData managed object setter. This isn’t really my field, so I don’t have any ready answers for you. Once you’ve symbolicated frames 4 through 2 you can start a new thread, requesting help from CoreData experts by tagging it with CoreData.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Wow that is SO helpful!!! Thank you so much!
Xcode doesn't symbolicate system frameworks in crash log
 
 
Q