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.