Xcode - UUID stimmt nicht mit Framework dSYMs überein
Ich habe ein OS X-Desktop-Xcode-Projekt, das ein weiteres 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?
Wenn ich das Archiv anschaue, von dem ich das Paket.app erzeugt habe, stimmt die UUID des dSYM des Frameworks nicht mit derjenigen überein, die in den Ordner "Frameworks" in der Datei .app:
kopiert wirdDas HCCommon-Framework innerhalb des .app-Pakets in der Archivdatei:
%Vor%vs. dSYM des HCCommon-Frameworks (im dSYMs-Verzeichnis in der Archivdatei):
%Vor%2 Antworten
Ich bin mir nicht 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.
Aber als Antwort auf Ihre Frage, wie Sie die bereits vorhandenen Absturzberichte mit den bereits vorhandenen .dSYMs symbolisieren können (vorausgesetzt, dass die UUIDs übereinstimmen, beziehen sie sich auf identischen Code und würden dies auch tun) Arbeit).
Ich habe Folgendes gefunden, um gut zu funktionieren, wenn Sie das spezifische dsym erzwingen müssen:
%Vor%Es ist sicherlich nicht so schön und im Allgemeinen führe ich die einzelnen Adressen über Atos manuell aus, aber das Ergebnis ist eine gültige Routine / Linienkombination (vorausgesetzt, Sie stimmen mit den richtigen Versionen überein usw).
Der <path_to_dsym_within_package> bezieht sich auf foo.framework.dSYM/Contents/Resources/DWARF/foo , gefolgt von Ihrem binären Namen, wobei foo der Name des Frameworks ist. Für uns funktioniert das auch für jede Art von Plugin.
Das <offset_of_framework> stammt aus der Spalte Offset im Crash-Protokoll, wobei gilt:
In diesem Fall ist die erste Hexadezimalzahl die Adresse, die zweite Hexadezimalzahl ist der Startoffset für das bestimmte Framework und der + Wert ist der Dezimaloffset 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 wird immer dwarfdump direkt verwendet:
<path_to_dSYM> ist der Pfad zum obersten Ordner ".dSYM" (anders als der obige Befehl atos ), und <offset> ist der Offset innerhalb des Moduls, was nicht so praktisch ist wie atos .
P.S. atos sollte in /usr/bin/atos installiert werden, wenn Sie die Dev Tools installiert haben.
Ich bin auch auf dieses Problem gestoßen. Nach einigen Nachforschungen stellte sich heraus, dass Xcode debug Framework-Builds in Release-Builds kopierte, aber offensichtlich dSYMs aus den korrekten Release-Binärdateien erstellte.
Dies war trotz der 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 die einzige mögliche Ursache ist, aber es lohnt sich, alle Pfade im Build-Protokoll doppelt zu überprüfen, da Xcode in diesem Fall nicht vor irgendetwas warnt.
Tags und Links objective-c xcode macos frameworks symbolicatecrash