Xcode - UUID mismatch with framework dSYMs

Question

I have an OSX desktop Xcode project which includes another Xcode project (a framework) as a dependency. When I build an archive of the app, it generates two dSYM packages - one for the app and one for the framework.

When I symbolicate crashes received from the app, symbols from the app package show up correctly (with file names and line numbers). However, symbols from the framework don't symbolicate at all - they just show the Framework name and memory address. Is there a way to symbolicate the parts of the stack trace involving the framework code?

Looking at the archive that I generated the.app package from, the UUID of the framework's dSYM doesn't match the one that gets copied into the "Frameworks" folder in the .app:

The HCCommon framework inside the .app package in the archive file:

/path/to/HipChat.xcarchive $ dwarfdump --uuid Products/Applications/HipChat.app/Contents/Frameworks/HCCommon.framework/HCCommon 
UUID: 84891A9C-19DB-3E16-BE7E-9D4056FFFB97 (x86_64) Products/Applications/HipChat.app/Contents/Frameworks/HCCommon.framework/HCCommon

vs the dSYM of the HCCommon framework (in the dSYMs directory in the archive file):

/path/to/HipChat.xcarchive $ dwarfdump --uuid dSYMs/HCCommon.framework.dSYM/Contents/Resources/DWARF/HCCommon 
UUID: 767F2D97-9E0B-3C4D-8337-FDF5A9CA2D81 (x86_64) dSYMs/HCCommon.framework.dSYM/Contents/Resources/DWARF/HCCommon

Answer 1

I'm not sure why your build is resulting in inconsistent dSYM UUIDs. When we do these kinds of builds (having spot-checked a few now), we have consistent UUIDs.

However, in answer to your question about how you can symbolicate the crash reports you've already received given the .dSYMs you already have (assuming for the moment that although the UUIDs match, they refer to identical code, and thus would work).

I have found the following to work well if you have to force the specific dsym:

atos -arch x86_64 -o <path_to_dsym_within_package> -l <offset_of_framework>

It's certainly not as pretty and generally I run the individual addresses through atos manually, but the result is a valid routine/line combination (assuming that you match the correct versions, etc.)

The <path_to_dsym_within_package> refers to foo.framework.dSYM/Contents/Resources/DWARF/foo followed by your binary name, where foo is the name of the framework. For us this works for any kind of plugin as well.

The <offset_of_framework> is from offset column in the crash log, where:

0 libsystem_kernel.dylib 0x7fff8e785ce2 0x7fff8e76f000 + 93410
1 libsystem_c.dylib 0x7fff871afa7a 0x7fff8716e000 + 268922
2 CTUtils 0x104e26c62 0x104e17000 + 64610

In this case, the first hex number is the address, the second hex number is the starting offset for the particular framework, and the + value is the decimal offset within the framework.

You'll need the second number (hex offset) for the command line above, and the first number to find the specific routine/line number.

In a worst-case scenario, there's always using dwarfdump directly, by using:

dwarfdump <path_to_dSYM> --arch x86_64 --lookup <offset>

<path_to_dSYM> is the path to the top level ".dSYM" folder (unlike the atos command above), and <offset> is the offset within the module, which isn't as convenient as atos.

P.S. atos should be installed in /usr/bin/atos if you have the dev tools installed.

Answer 2

I encountered this problem too. After some investigation, it turned out that Xcode was copying debug framework builds into release builds, but, apparently, creating dSYMs from the correct release binaries.

This was despite using Xcode to add the framework dependencies from the workspace. Eventually I found out why: the frameworks were included the project with their location "Relative to Group" for some reason. After I made sure all were "Relative to Build Product", it solved the problem for me. Not saying it is the only possible cause, but it's worth double-checking all the paths in the build log, because Xcode won't warn about anything in this case.