Xcode - UUID stimmt nicht mit Framework dSYMs überein

Question

Ich habe ein OS X Desktop Xcode Projekt, das ein anderes Xcode Projekt (ein Framework) als Abhängigkeit enthält. Wenn ich ein Archiv der App erstelle, erzeugt es zwei dSYM-Pakete - eines für die App und eines für das Framework.

Wenn ich Abstürze symbolisiert, die von der App empfangen wurden, werden Symbole aus dem App-Paket korrekt angezeigt (mit Dateinamen und Zeilennummern). Symbole aus dem Framework werden jedoch nicht symbolisiert - sie zeigen nur den Framework-Namen und die Speicheradresse an. Gibt es eine Möglichkeit, die Teile des Stack-Trace mit dem Framework-Code zu symbolisieren?

im Archiv suchen, das I-Paket erzeugt the.app aus, die UUID des DSYM der Rahmen stimmt nicht mit der übereinstimmt, die in den Ordner „Frameworks“ in der .app kopiert wird:

Der HCCommon Rahmen in dem .app-Paket in der Archivdatei:

/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 

gegen die DSYM des HCCommon Rahmen (im dSYMs Verzeichnis in der Archivdatei):

/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 n bin Sicher, warum Ihr Build zu inkonsistenten dSYM UUIDs führt. Wenn wir diese Arten von Builds durchführen (haben wir jetzt ein paar wenige überprüft), haben wir konsistente UUIDs.

Antwort auf Ihre Frage darüber, wie Sie die Crash-Berichte, die Sie bereits erhalten haben, mit den bereits vorhandenen .dSYMs symbolisieren (vorausgesetzt, die UUIDs stimmen überein, beziehen sich auf identischen Code und somit würde funktionieren).

Ich habe das gefunden gut folgenden arbeiten, wenn Sie die spezifische DSYM zu zwingen, haben:

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

Es ist sicherlich nicht so schön und laufen in der Regel ich die einzelnen Adressen durch atos manuell, aber das Ergebnis ist ein gültiges Routine/Line-Kombination (unter der Annahme, dass Sie die richtigen Versionen übereinstimmen, etc.)

die <path_to_dsym_within_package> auf foo.framework.dSYM/Contents/Resources/DWARF/foo bezieht sich durch die Binärdatei Namen gefolgt, wo foo der Name des Rahmens ist. Für uns funktioniert das auch für jede Art von Plugin.

Die <offset_of_framework> ist aus Offset-Spalte in dem Crash-Protokoll, wobei gilt:

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

In diesem Fall ist die erste Hexadezimalzahl die Adresse ist, wird die zweite hexadezimale Zahl des für den jeweiligen Rahmen Start-Offset und Der Wert + ist der Dezimal-Offset innerhalb des Frameworks.

Sie benötigen die zweite Nummer (Hex-Offset) für die obige Befehlszeile und die erste Nummer, um die spezifische Routine/Zeilennummer zu finden.

In einem Worst-Case-Szenario ist es dwarfdump immer mit direkt, unter Verwendung von:

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

<path_to_dSYM> der Weg in die obersten Ebene ist ".dSYM" -Ordner (im Gegensatz zum atos Befehl oben) und <offset> ist der Offset innerhalb des Moduls, der nicht so bequem wie atos ist.

P.S.atos sollte in /usr/bin/atos installiert werden, wenn Sie die Dev-Tools installiert haben.

Answer 2

Ich stieß auch auf dieses Problem. Nach einigen Nachforschungen stellte sich heraus, dass Xcode Debug Framework-Builds in Release-Builds kopierte, aber offenbar dSYMs aus den korrekten Release-Binärdateien erstellte.

Dies war trotz Verwendung von Xcode, um die Framework-Abhängigkeiten aus dem Arbeitsbereich hinzuzufügen. Irgendwann fand ich heraus, warum: Die Frameworks wurden aus irgendeinem Grund in das Projekt mit ihrem Standort "Relative to Group" aufgenommen. Nachdem ich sichergestellt hatte, dass alle "Relative to Build Product" waren, löste es das Problem für mich. Ich sage nicht, dass dies der einzig mögliche Grund ist, aber es lohnt sich, alle Pfade im Build-Protokoll doppelt zu überprüfen, da Xcode in diesem Fall nicht vor irgendetwas warnt.