Chcę spróbować symbolizować raporty o awariach mojej aplikacji iPhone.
Pobrałem raporty o awariach z iTunes Connect. Mam plik binarny aplikacji przesłany do App Store i mam plik dSYM, który został wygenerowany w ramach kompilacji.
Mam wszystkie te pliki razem w jednym katalogu, który jest indeksowany przez centrum uwagi.
Co teraz?
Próbowałem wywołać:
symbolicatecrash crashreport.crash myApp.app.dSYM
i po prostu wyświetla ten sam tekst, który jest na początku w raporcie o awarii, a nie symbolizuje.
czy robię coś źle?
ios
crash-reports
symbolicate
Jasarien
źródło
źródło
symbolicatecrash
Podaję , gdzie znaleźć polecenie, jak go użyć i jak znaleźć plik dSYM potrzebny do symbolizacji.Odpowiedzi:
Kroki analizy raportu o awarii z Apple:
Skopiuj plik .app wydania, który został wypchnięty do sklepu z aplikacjami, plik .dSYM, który został utworzony w momencie wydania, a raport o awarii otrzyma od APPLE do FOLDERU .
OTWÓRZ aplikację terminala i przejdź do folderu utworzonego powyżej (za pomocą
cd
polecenia)Uruchom
atos -arch armv7 -o APPNAME.app/APPNAME MEMORY_LOCATION_OF_CRASH
. Lokalizacja pamięci powinna być tą, w której aplikacja uległa awarii zgodnie z raportem.Dawny:
atos -arch armv7 -o 'APPNAME.app'/'APPNAME' 0x0003b508
To pokaże dokładną linię, nazwę metody, która spowodowała awarię.
Dawny:
[classname functionName:]; -510
Symbolizuje IPA
jeśli używamy IPA do symbolizacji - po prostu zmień nazwę rozszerzenia .ipa na .zip, rozpakuj go, a następnie otrzymamy folder ładunku zawierający aplikację. W takim przypadku nie potrzebujemy pliku .dSYM.
Uwaga
Może to działać tylko wtedy, gdy w pliku binarnym aplikacji nie ma symboli. Domyślnie kompilacje wydania usuwają symbole. Możemy to zmienić w ustawieniach kompilacji projektu „Usuń symbole debugowania podczas kopiowania” na NIE.
Więcej szczegółów zobacz ten post
źródło
atos -o myApp.app/Contents/MacOS/myApp 0x0000000100001f2c
i dostaniesz-[HUDWindow sizedHUDBackground] (in myApp) + 1197
Po przeczytaniu wszystkich tych odpowiedzi tutaj, aby symbolizować dziennik awarii (i wreszcie powodzenie), myślę, że brakuje tutaj kilku punktów, które są naprawdę ważne, aby ustalić, dlaczego wywołanie symbolicatecrash nie generuje symbolicznego wyniku.
Istnieją 3 zasoby, które muszą pasować do siebie podczas symbolizowania dziennika awarii:
example.crash
) Wyeksportowany z organizatora XCode lub otrzymany z iTunes Connect..app
Pakiet (tjexample.app
), która sama w sobie zawiera aplikację binarny należącej do katastrofy dzienniku. Jeśli masz.ipa
pakiet (tj.example.ipa
), Możesz.app
go rozpakować, rozpakowując.ipa
pakiet (tjunzip example.ipa
.). Następnie.app
pakiet znajduje się w rozpakowanymPayload/
folderze..dSYM
Opakowanie zawierające symbole debugowania (tjexample.app.dSYM
)Przed rozpoczęciem symbolizacji należy sprawdzić, czy wszystkie te artefakty są zgodne, co oznacza, że dziennik awarii należy do posiadanego pliku binarnego i że symbole debugowania są tymi, które powstają podczas kompilacji tego pliku binarnego.
Każdy plik binarny jest oznaczony identyfikatorem UUID, który można zobaczyć w pliku dziennika awarii:
W tym wyciągu dziennik awarii należy do obrazu binarnego aplikacji o nazwie example.app/example z UUID
aa5e633efda8346cab92b01320043dc3
.Możesz sprawdzić UUID pakietu binarnego, który masz za pomocą dwarfdump:
Następnie powinieneś sprawdzić, czy symbole debugowania, które posiadasz, również należą do tego pliku binarnego:
W tym przykładzie wszystkie zasoby pasują do siebie i powinieneś być w stanie symbolizować swój stacktrace.
Przejdź do
symbolicatecrash
skryptu:W Xcode 8.3 powinieneś być w stanie wywołać skrypt za pośrednictwem
Jeśli go nie ma, możesz uruchomić
find . -name symbolicatecrash
w katalogu Xcode.app, aby go znaleźć.Jak widać, nie podano już żadnych parametrów. Skrypt musi więc znaleźć symbole binarne i symbole debugowania aplikacji, uruchamiając wyszukiwanie punktowe. Przeszukuje symbole debugowania za pomocą określonego indeksu o nazwie
com_apple_xcode_dsym_uuids
. Możesz wykonać to wyszukiwanie samodzielnie:odpowiednio
Pierwsze wywołanie w centrum uwagi daje wszystkie zindeksowane pakiety dSYM, a drugie daje
.dSYM
pakiety o określonym UUID. Jeśli narzędzie Spotlight nie znajdzie Twojego.dSYM
pakietusymbolicatecrash
, nie będzie. Jeśli robisz te wszystkie rzeczy, np. W podfolderze swojego~/Desktop
reflektora, powinno być w stanie znaleźć wszystko.Jeśli
symbolicatecrash
znajdzie twój.dSYM
pakiet, powinien pojawić się wiersz taki jak poniżejsymbolicate.log
:W celu znalezienia
.app
pakietu wywoływane jest wyszukiwanie punktowe, takie jaksymbolicatecrash
:Jeśli
symbolicatecrash
znajdziesz.app
paczkę, powinien znajdować się następujący fragmentsymbolicate.log
:Jeśli wszystkie te zasoby zostaną znalezione
symbolicatecrash
, powinien wydrukować symboliczną wersję dziennika awarii.Jeśli nie, możesz przekazać swoje pliki dSYM i .app bezpośrednio.
Uwaga: Symboliczny ślad będzie wyprowadzany na terminal, a nie
symbolicate.log
.źródło
No crash report version in testlog.crash at /usr/bin/symbolicatecrash line 921.
DEVELOPER_DIR
zmienną środowiskową jeśli skrypt narzeka na to tak:export DEVELOPER_DIR=`xcode-select --print-path`
. Dodałem tę linię do mojej~/.bash_profile
. Zobacz stackoverflow.com/q/11682789/350761<SYMBOL_PATH> Additional search paths in which to search for symbol rich binaries
-o | --output <OUTPUT_FILE> The symbolicated log will be written to OUTPUT_FILE. Defaults to "-" (i.e. stdout) if not specified
-d | --dsym <DSYM_BUNDLE> Adds additional dSYM that will be consulted if and when a binary's UUID matches (may be specified more than once)
W najnowszej wersji Xcode (3.2.2) możesz przeciągać i upuszczać dowolne raporty o awariach do sekcji Dzienniki urządzeń w Xcode Organizer i będą one automatycznie symbolizowane dla Ciebie. Myślę, że to działa najlepiej, jeśli zbudowałeś tę wersję aplikacji za pomocą kompilacji i archiwizacji (również stanowicej część Xcode 3.2.2)
źródło
Zrobiłem to pomyślnie, wykonując następujące kroki.
Krok 1: Utwórz folder na pulpicie, nadaję mu nazwę „CrashReport” i umieszczam w nim trzy pliki („MYApp.app”, „MyApp.app.dSYM”, „MYApp_2013-07-18.crash”).
Krok 2: Otwórz Finder i przejdź do aplikacji, w której znajdziesz aplikację Xcode, kliknij ją prawym przyciskiem myszy i kliknij „Pokaż zawartość opakowania”, a następnie wykonaj tę prostą ścieżkę. „Spis treści-> Deweloper-> Platformy-> iPhoneOS.platform-> Deweloper-> Biblioteka-> PrivateFrameworks-> DTDeviceKit.framework -> Wersje- > A-> Zasoby”
LUB
„Spis treści-> Deweloper-> Platformy-> iPhoneOS.platform-> Deweloper-> Biblioteka-> PrivateFrameworks-> DTDeviceKitBase.framework -> Wersje- > A-> Zasoby”
LUB
Dla Xcode 6 i wyższych ścieżka to Aplikacje / Xcode.app / Contents / SharedFrameworks / DTDeviceKitBase.framework / Versions / A / Resources
Jeśli znajdziesz plik „symbolicatecrash”, skopiuj go i wklej do folderu „CrashReport”.
Krok 3: uruchom terminal, uruchom 3 polecenia
cd / Users / mac38 / Desktop / CrashReport i naciśnij przycisk Enter
eksportuj DEVELOPER_DIR = "/ Applications / Xcode.app / Contents / Developer" i naciśnij Enter
źródło
Unknown option: A
symboliczną katastrofę, ale proces i tak trwałKroki do automatycznego symbolizowania raportu o awarii przy użyciu XCode:
AKTUALIZACJA DLA XCODE 9
Podłącz dowolne urządzenie iOS do komputera Mac (tak fizyczne, tak, wiem, że to głupie)
Wybierz „Urządzenia” z menu „Okno”
Kliknij swoje urządzenie po lewej, a ZOBACZ DZIENNIKI URZĄDZENIA po prawej
Czekać. Pojawienie się może zająć minutę. Może
Command-A
wtedyDelete
to przyspieszy.Krytyczny nieudokumentowany krok: zmień nazwę raportu o awarii otrzymanego z iTunesConnect z
.txt
rozszerzenia na.crash
rozszerzeniePrzeciągnij raport o awarii do tego obszaru po lewej stronie
A następnie Xcode symbolizuje raport o awarii i wyświetla wyniki.
Źródło: https://developer.apple.com/library/ios/technotes/tn2151/_index.html
źródło
Korzystam z Airbrake w moich aplikacjach, co dość dobrze wykonuje zdalne rejestrowanie błędów.
Oto jak symbolizuję ich za pomocą atos, jeśli ślad tego potrzebuje:
W Xcode (4.2) przejdź do organizatora, kliknij prawym przyciskiem myszy archiwum, z którego został wygenerowany plik .ipa.
W terminalu, cd do xcarchive na przykład
MyCoolApp 10-27-11 1.30 PM.xcarchive
Wpisz następujące informacje
atos -arch armv7 -o 'MyCoolApp.app'/'MyCoolApp'
(nie zapomnij o pojedynczych cudzysłowach)Nie dołączam mojego symbolu do tego połączenia. Otrzymujesz kursor blokowy na pustej linii.
Następnie kopiuję / wklejam kod symbolu w tym kursorze blokowym i wciskam Enter. Zobaczysz coś takiego:
-[MyCoolVC dealloc] (in MyCoolApp) (MyCoolVC.m:34)
Wróciłeś do kursora blokowego i możesz wkleić inne symbole.
Możliwość przejścia przez jeden ślad bez ponownego wprowadzania pierwszego elementu jest przyjemną oszczędnością czasu.
Cieszyć się!
źródło
Umieszczam także dsym, pakiet aplikacji i dziennik awarii razem w tym samym katalogu przed uruchomieniem symbolicate crash
Następnie używam tej funkcji zdefiniowanej w moim .profile, aby uprościć uruchamianie symbolicatecrash:
Dodane tam argumenty mogą ci pomóc.
Możesz sprawdzić, czy reflektor „widzi” pliki dyskowe, uruchamiając polecenie:
Znajdź dsym, który masz w swoim katalogu.
UWAGA: Od najnowszego Xcode nie ma już katalogu Deweloperów. Możesz znaleźć to narzędzie tutaj:
/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Vers ions / A / Resources / symbolicatecrash
źródło
Prosta i zaktualizowana odpowiedź dla xcode 6.1.1.
KROKI
1. Xkod> Okno> Urządzenia.
2. Wybierz urządzenie z listy urządzeń w sekcji URZĄDZENIA.
3. Wybierz opcję Wyświetl dzienniki urządzeń.
4. W sekcji Wszystkie dzienniki możesz bezpośrednio przeciągnąć upuszczenie raportu. Katastrofa
5.Xcode automatycznie zasygnalizuje dla ciebie raport o awarii.
6. Możesz znaleźć symboliczny raport o awarii, dopasowując jego datę / godzinę do daty / godziny wymienionej w raporcie o awarii.
źródło
Mimo że opracowuję aplikacje od kilku lat, po raz pierwszy debugowałem plik binarny i czułem się jak kompletny NOOB, który zastanawia się, gdzie są wszystkie pliki, tj. Gdzie jest * .app * .dSYM i dzienniki awarii? Musiałem przeczytać wiele postów, aby to rozgryźć. Obraz jest wart tysiąca słów i mam nadzieję, że ten post pomoże każdemu innemu w przyszłości.
1- Najpierw przejdź do itunesconnect i pobierz swoje dzienniki awarii. UWAGA: w większości przypadków może pojawić się komunikat „Przesłano zbyt mało raportów, aby raport mógł zostać wyświetlony”. Zasadniczo niewystarczająca liczba użytkowników przesłała do Apple raporty dziennika awarii, w którym to przypadku nie można wiele zrobić.
2- Teraz, jeśli nie zmieniłeś kodu od czasu przesłania go do Apple, uruchom Xcode dla tego projektu i ponownie wykonaj Product -> Archive. W przeciwnym razie po prostu znajdź ostatnio przesłany plik binarny i kliknij go prawym przyciskiem myszy.
źródło
W Xcode 4.2.1 otwórz Organizer , a następnie przejdź do Library / Device Logs i przeciągnij plik .crash na listę dzienników awarii. Po kilku sekundach będzie to symbolizowane.
Pamiętaj, że musisz użyć tego samego wystąpienia Xcode, w którym została zarchiwizowana oryginalna kompilacja (tzn. Archiwum dla twojej kompilacji musi istnieć w Organizatorze ).
źródło
Dzięki Xcode 4 zadanie jest jeszcze prostsze:
i voila. Plik dziennika jest importowany i automatycznie symbolizowany. Pod warunkiem, że najpierw zarchiwizowałeś kompilację, używając Xcode -> Produkt -> Archiwizuj .
źródło
Magiczny Xcode Organizer nie jest tak magiczny w symbolizowaniu mojej aplikacji. Nie otrzymałem żadnych symboli dla raportów o awariach, które otrzymałem od Apple po nieudanym przesłaniu aplikacji.
Próbowałem użyć wiersza polecenia, umieszczając raport o awarii w tym samym folderze, co plik .app (przesłany do sklepu) i plik .dSYM:
Dostarczyło to tylko symboli dla mojej aplikacji, a nie podstawowego kodu podstawowego, ale było to lepsze niż zrzut liczbowy, który daje mi Organizator i wystarczyło, abym znalazł i naprawić awarię, którą miała moja aplikacja. Jeśli ktoś wie, jak to rozszerzyć, aby uzyskać symbole Fundacji, będzie to mile widziane.
źródło
W moim przypadku przeciągałem raporty o awariach bezpośrednio z Poczty do Organizatora. Z jakiegoś powodu zapobiegło to symbolizacji raportów o awariach (chciałbym wiedzieć, dlaczego).
Najpierw skopiuj raporty o awariach na pulpit, a następnie przeciągnij je stamtąd do Organizatora, aby odpowiednio je symbolizować.
Bardzo konkretny przypadek, wiem. Ale pomyślałem, że podzielę się na wszelki wypadek.
źródło
Oto kolejny problem, który mam z symbolicznym zrzutem - nie będzie działać z aplikacjami, które mają spacje w swoim pakiecie (tj. „Testuj aplikację.”). Uwaga: Nie sądzę, aby podczas przesyłania mogły występować spacje w ich nazwach, więc i tak powinieneś je usunąć, ale jeśli masz już awarie wymagające analizy, wstaw symbolicatecrash (4.3 GM) jako taki:
źródło
Dla tych, którzy używają Airbrake, powyżej jest solidna odpowiedź, ale nie działałoby to dla mnie bez modyfikacji:
Działa dla niektórych adresów pamięci, ale nie dla innych, nie wiem, dlaczego ...
źródło
Połączenie, które działało dla mnie było:
Korzystając z atos, nie byłem w stanie rozwiązać poprawnych informacji o symbolach z adresami i przesunięciami, które były w raporcie o awarii. Kiedy to zrobiłem, widzę coś bardziej znaczącego i wydaje się, że jest to uzasadniony ślad stosu.
źródło
Musiałem dużo włamać się do skryptu symbolicatecrash, aby działał poprawnie.
O ile mogę stwierdzić, symboliczna katastrofa wymaga, aby .app znajdował się w tym samym katalogu co .dsym. Użyje .dsym do zlokalizowania .app, ale nie użyje dsym do znalezienia symboli.
Powinieneś zrobić kopię symbolicznej ucieczki przed wypróbowaniem tych poprawek, które sprawią, że będzie wyglądać w dsym:
Wokół linii 212 w funkcji getSymbolPathFor_dsymUuid
Wokół linii 265 w funkcji matchUUID
źródło
Jest to proste, po wielu poszukiwaniach znalazłem wyraźne kroki, które symbolizują cały plik dziennika awarii.
szczęśliwego kodowania,
Riyaz
źródło
Wolę skrypt, który będzie symbolizował wszystkie moje dzienniki awarii.
Warunki wstępne
Utwórz folder i umieść tam 4 rzeczy:
symbolicatecrash
skrypt perl - istnieje wiele odpowiedzi SO, które mówią o jego lokalizacjiArchiwum kompilacji pasujące do awarii (z Xcode Organizer. Proste jak
Show in Finder
i skopiuj) [Nie wiem, czy to konieczne]Wszystkie
xccrashpoint
pakiety - (z Xcode Organizer.Show in Finder
Możesz skopiować wszystkie pakiety z katalogu lub pojedynczy xccrashpoint, który chciałbyś symbolizować)Dodaj ten krótki skrypt do katalogu:
Scenariusz
Po uruchomieniu skryptu otrzymasz 2 katalogi.
allCrashes
- wszystkie awarie ze wszystkichxccrashpoint
będą tam.symboledCrashes
- te same awarie, ale teraz wszystkie symbole.NIE musisz usuwać katalogu ze starych awarii przed uruchomieniem skryptu. wyczyści się automatycznie. powodzenia!
źródło
Dowiedziałem się, że większość proponowanych alternatyw nie działa w najnowszym XCode (testowanym z Xcode 10). Na przykład nie miałem szczęścia przeciągać dzienników .crash w Xcode -> Organizator -> Dzienniki urządzeń - widok.
Polecam korzystanie z narzędzia Symbolicator https://github.com/agentsim/Symbolicator
źródło
Aby symbolizować awarie, Spotlight musi być w stanie znaleźć plik .dSYM, który został wygenerowany w tym samym czasie, co plik binarny przesłany do Apple. Ponieważ zawiera informacje o symbolu, nie będziesz miał szczęścia, jeśli nie będzie dostępny.
źródło
Byłem trochę zrzędliwy z powodu faktu, że nic tutaj nie wydaje się „po prostu działać”, więc przeprowadziłem dochodzenie, a wynik jest następujący:
Skonfiguruj: zaplecze QuincyKit, które odbiera raporty. Nie ustawiono żadnej symboliki, ponieważ nie mogłem nawet dowiedzieć się, co oni sugerują, żebym zrobił, aby działało.
Poprawka: pobierz raporty o awariach z serwera online. Nazywa się je „awarią” i domyślnie przechodzą do folderu ~ / Downloads /. Mając to na uwadze, ten skrypt „zrobi właściwą rzecz”, a raporty o awariach przejdą do Xcode (Organizator, logi urządzeń) i symbolizacja zostanie wykonana.
Scenariusz:
Rzeczy można zautomatyzować do miejsca, w którym można przeciągać i upuszczać w Xcode Organizer, wykonując dwie czynności, jeśli używasz QuincyKit / PLCR.
Po pierwsze, musisz edytować zdalny skrypt admin / actionapi.php ~ linia 202. Wygląda na to, że nie ma prawidłowej sygnatury czasowej, więc plik kończy się nazwą „crash”, której Xcode nie rozpoznaje (chce czegoś awaria kropki):
Po drugie, w boku iOS w QuincyKit BWCrashReportTextFormatter.m ~ linii 176, zmiany
@"[TODO]"
do@"TODO"
obejść złe znaki.źródło
atos jest przestarzałe, więc jeśli używasz OSX 10.9 lub nowszego, może być konieczne uruchomienie
xcrun atos
źródło
Lubię używać Textwrangler do wskazywania błędów w binarnym odrzuceniu przesłania aplikacji. (Dane awarii zostaną znalezione na koncie itunesConnect.) Korzystając z powyższej metody Sachina, kopiuję original.crash do TextWrangler, a następnie kopiuję utworzony przeze mnie plik symbolicatecrash do innego pliku TextWrangler. Porównanie dwóch plików wskazuje różnice. Plik symbolicatecrash będzie miał różnice wskazujące na problem z plikiem i linią.
źródło
Używamy Google Crashlytics do nadzorowania dzienników awarii, uczucie jest bardzo aktualne i wygodne w użyciu.
Łącza do dokumentów : https://docs.fabric.io/apple/crashlytics/missing-dsyms.html#missing-dsyms
Wszystko o zaginionej tkaninie dSYM zawiera narzędzie do automatycznego przesyłania dSYM projektu. Narzędzie jest uruchamiane za pomocą skryptu / run, który jest dodawany do fazy kompilacji skryptu Run podczas procesu wdrażania. Mogą jednak wystąpić pewne sytuacje, gdy przesyłanie dSYM nie powiedzie się z powodu unikatowych konfiguracji projektu lub jeśli używasz Bitcode w swojej aplikacji. Gdy przesyłanie się nie powiedzie, Crashlytics nie może symbolizować i wyświetlać awarii, a na pulpicie nawigacyjnym Fabric pojawi się ostrzeżenie „Missing dSYM”.
Brakujące moduły dSYM można ręcznie przesłać, wykonując czynności opisane poniżej.
Uwaga: Jako alternatywa dla narzędzia do automatycznego przesyłania dSYM, Fabric udostępnia narzędzie wiersza polecenia (symbole przesyłania), które można ręcznie skonfigurować do uruchamiania w ramach procesu kompilacji projektu. Instrukcje konfiguracji znajdują się w sekcji symboli przesyłania poniżej.
...
źródło