Xcode - Niezgodność UUID z frameworkami dSYMs

Question

Mam projekt Xcode na pulpicie OSX, który zawiera inny projekt Xcode (framework) jako zależność. Kiedy buduję archiwum aplikacji, generuje ona dwa pakiety dSYM - jeden dla aplikacji i jeden dla frameworka.

Kiedy symbolizuję awarie odebrane z aplikacji, symbole z pakietu aplikacji są wyświetlane poprawnie (wraz z nazwami plików i numerami linii). Jednak symbole z frameworka nie symbolizują w ogóle - pokazują tylko nazwę i adres pamięci. Czy istnieje sposób na oznaczenie części śladu stosu zawierającego kod strukturalny?

Patrząc na archiwum, że pakiet z wygenerowanym the.app, UUID ram za dSYM nie odpowiada ten, który zostanie skopiowany do folderu „Ramki” w .app:

Ramy HCCommon wewnątrz opakowania .app w archiwum:

/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 dSYM ram HCCommon (w katalogu dSYMs w archiwum):

/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

jestem n nie wiesz, dlaczego twoja kompilacja prowadzi do niespójnych identyfikatorów UUID dSYM. Kiedy robimy tego typu kompilacje (po kilku skontrolowanych punktach) mamy spójne identyfikatory UUID.

Jednak w odpowiedzi na pytanie, jak możesz oznaczyć raporty o awariach, które już otrzymałeś, biorąc pod uwagę .dSYM, które już posiadasz (zakładając w tym momencie, że chociaż identyfikatory UUID są zgodne, odnoszą się do identycznego kodu, a tym samym do pracowałbym).

Znalazłem następujące działać dobrze, jeśli trzeba wymusić konkretną dsym:

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

to na pewno nie jest tak ładny i ogólnie uruchomić poszczególne adresy przez Atos ręcznie, ale wynik jest prawidłowy połączenie rutyna/linia (zakładając, że można dopasować odpowiednie wersje, itd.)

<path_to_dsym_within_package> dotyczy foo.framework.dSYM/Contents/Resources/DWARF/foo następnie przez binarnego nazwie, gdzie foo jest nazwą ram. Dla nas działa to również dla każdego rodzaju wtyczki.

<offset_of_framework> jest z przesunięciem kolumny w dzienniku katastrofy, gdzie:

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

W tym przypadku, pierwszy numer Hex jest adresem, drugi numer Hex to początkowy offset dla danej ramy, a wartość + jest dziesiętnym przesunięciem w ramach.

Będziesz potrzebował drugiej cyfry (przesunięcie heksadecymalne) dla powyższej linii komend i pierwszej liczby, aby znaleźć konkretną procedurę/numer linii.

W najgorszym scenariuszu, zawsze przy użyciu dwarfdump bezpośrednio, za pomocą:

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

<path_to_dSYM> jest ścieżką do najwyższego poziomu „.dSYM” folder (w przeciwieństwie do polecenia atos powyżej) i <offset> jest przesunięciem w module, co nie jest tak wygodne jak atos.

P.S.atos powinien być zainstalowany w /usr/bin/atos, jeśli masz zainstalowane narzędzia dev.

Answer 2

Napotkałem ten problem. Po pewnym dochodzeniu okazało się, że Xcode kopiuje kompilacje do debugowania w kompilacje wydań, ale najwyraźniej tworzy dSYM z prawidłowych plików binarnych.

Było tak pomimo użycia Xcode do dodania zależności ramowych z obszaru roboczego. W końcu dowiedziałem się, dlaczego: do ram dołączono projekt z ich lokalizacją "Względem grupy" z jakiegoś powodu. Po upewnieniu się, że wszystkie są "Względem budowania produktu", rozwiązało to problem dla mnie. Nie twierdząc, że jest to jedyna możliwa przyczyna, ale warto dwukrotnie sprawdzić wszystkie ścieżki w dzienniku budowy, ponieważ Xcode nie będzie ostrzegał o niczym w tym przypadku.