Symbolizuje raporty awarii aplikacji na iPhone'a

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?

Kroki analizy raportu o awarii z Apple:

1. 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 .

2. OTWÓRZ aplikację terminala i przejdź do folderu utworzonego powyżej (za pomocą cdpolecenia)

3. 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

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:

1. Sam plik dziennika awarii (tj. example.crash) Wyeksportowany z organizatora XCode lub otrzymany z iTunes Connect.
2. .appPakiet (tj example.app), która sama w sobie zawiera aplikację binarny należącej do katastrofy dzienniku. Jeśli masz .ipapakiet (tj. example.ipa), Możesz .appgo rozpakować, rozpakowując .ipapakiet (tj unzip example.ipa.). Następnie .apppakiet znajduje się w rozpakowanym Payload/folderze.
3. .dSYMOpakowanie zawierające symbole debugowania (tj example.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:

...
Binary Images:
0xe1000 -    0x1f0fff +example armv7  <aa5e633efda8346cab92b01320043dc3> /var/mobile/Applications/9FB5D11F-42C0-42CA-A336-4B99FF97708F/example.app/example
0x2febf000 - 0x2fedffff  dyld armv7s  <4047d926f58e36b98da92ab7a93a8aaf> /usr/lib/dyld
...

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:

dwarfdump --uuid example.app/example
UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app/example

Następnie powinieneś sprawdzić, czy symbole debugowania, które posiadasz, również należą do tego pliku binarnego:

dwarfdump --uuid example.app.dSYM
UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app.dSYM/Contents/Resources/DWARF/example

W tym przykładzie wszystkie zasoby pasują do siebie i powinieneś być w stanie symbolizować swój stacktrace.

Przejdź do symbolicatecrashskryptu:

W Xcode 8.3 powinieneś być w stanie wywołać skrypt za pośrednictwem

/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash -v example.crash 2> symbolicate.log

Jeśli go nie ma, możesz uruchomić find . -name symbolicatecrashw 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:

mdfind 'com_apple_xcode_dsym_uuids = *'

odpowiednio

mdfind "com_apple_xcode_dsym_uuids == AA5E633E-FDA8-346C-AB92-B01320043DC3"

Pierwsze wywołanie w centrum uwagi daje wszystkie zindeksowane pakiety dSYM, a drugie daje .dSYMpakiety o określonym UUID. Jeśli narzędzie Spotlight nie znajdzie Twojego .dSYMpakietu symbolicatecrash, nie będzie. Jeśli robisz te wszystkie rzeczy, np. W podfolderze swojego ~/Desktopreflektora, powinno być w stanie znaleźć wszystko.

Jeśli symbolicatecrashznajdzie twój .dSYMpakiet, powinien pojawić się wiersz taki jak poniżej symbolicate.log:

@dsym_paths = ( <SOME_PATH>/example.app.dSYM/Contents/Resources/DWARF/example )

W celu znalezienia .apppakietu wywoływane jest wyszukiwanie punktowe, takie jak symbolicatecrash:

mdfind "kMDItemContentType == com.apple.application-bundle && (kMDItemAlternateNames == 'example.app' || kMDItemDisplayName == 'example' || kMDItemDisplayName == 'example.app')"

Jeśli symbolicatecrashznajdziesz .apppaczkę, powinien znajdować się następujący fragment symbolicate.log:

Number of symbols in <SOME_PATH>/example.app/example: 2209 + 19675 = 21884
Found executable <SOME_PATH>/example.app/example
-- MATCH

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.

symbolicatecrash -v --dsym <SOME_PATH>/<App_URI>.app.dSYM/<APP_NAME>.app.dsym <CRASHFILE> <SOME_OTHER_PATH>/<APP_NAME>.app/<APP_NAME> > symbolicate.log

Uwaga: Symboliczny ślad będzie wyprowadzany na terminal, a nie symbolicate.log.

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)

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

1. cd / Users / mac38 / Desktop / CrashReport i naciśnij przycisk Enter

2. eksportuj DEVELOPER_DIR = "/ Applications / Xcode.app / Contents / Developer" i naciśnij Enter

3. ./symbolicatecrash -A -v MYApp_2013-07-18.crash MyApp.app.dSYM i naciśnij klawisz Enter Now jego Gotowe .. (UWAGA: wersje około 6.4 lub nowsze nie mają opcji -A - po prostu ją pomiń).

Kroki do automatycznego symbolizowania raportu o awarii przy użyciu XCode:

AKTUALIZACJA DLA XCODE 9

1. Podłącz dowolne urządzenie iOS do komputera Mac (tak fizyczne, tak, wiem, że to głupie)

2. Wybierz „Urządzenia” z menu „Okno”

3. Kliknij swoje urządzenie po lewej, a ZOBACZ DZIENNIKI URZĄDZENIA po prawej

4. Czekać. Pojawienie się może zająć minutę. Może Command-Awtedy Deleteto przyspieszy.

5. Krytyczny nieudokumentowany krok: zmień nazwę raportu o awarii otrzymanego z iTunesConnect z.txtrozszerzenia na.crashrozszerzenie

6. Przecią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

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:

1. W Xcode (4.2) przejdź do organizatora, kliknij prawym przyciskiem myszy archiwum, z którego został wygenerowany plik .ipa.

2. W terminalu, cd do xcarchive na przykładMyCoolApp 10-27-11 1.30 PM.xcarchive

3. Wpisz następujące informacje atos -arch armv7 -o 'MyCoolApp.app'/'MyCoolApp' (nie zapomnij o pojedynczych cudzysłowach)

4. Nie dołączam mojego symbolu do tego połączenia. Otrzymujesz kursor blokowy na pustej linii.

5. Następnie kopiuję / wklejam kod symbolu w tym kursorze blokowym i wciskam Enter. Zobaczysz coś takiego:

   -[MyCoolVC dealloc] (in MyCoolApp) (MyCoolVC.m:34)

6. 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ę!

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:

function desym
{
    /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash -A -v $1 | more
}

Dodane tam argumenty mogą ci pomóc.

Możesz sprawdzić, czy reflektor „widzi” pliki dyskowe, uruchamiając polecenie:

mdfind 'com_apple_xcode_dsym_uuids = *'

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

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.

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.

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 ).

Dzięki Xcode 4 zadanie jest jeszcze prostsze:

• otwórz Organizator ,
• kliknij Biblioteka | Zaloguj się do urządzenia w lewej kolumnie
• kliknij przycisk „ Importuj ” u dołu ekranu ...

i voila. Plik dziennika jest importowany i automatycznie symbolizowany. Pod warunkiem, że najpierw zarchiwizowałeś kompilację, używając Xcode -> Produkt -> Archiwizuj .

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:

$ symbolicatecrash "My App_date_blahblah-iPhone.crash" "My App.app"

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.

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.

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:

240c240
<         my $cmd = "mdfind \"kMDItemContentType == com.apple.application-bundle && kMDItemFSName == $exec_name.app\"";
---
>         my $cmd = "mdfind \"kMDItemContentType == com.apple.application-bundle && kMDItemFSName == '$exec_name.app'\"";
251c251
<             my $cmd = "find \"$archive_path/Products\" -name $exec_name.app";
---
>             my $cmd = "find \"$archive_path/Products\" -name \"$exec_name.app\"";

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 ...

• Utwórz nowy katalog na komputerze lub w dowolnym miejscu
• Znajdź odpowiednie archiwum w organizatorze Xcode
• Kliknij dwukrotnie, aby odsłonić w wyszukiwarce
• Kliknij dwukrotnie, aby wyświetlić zawartość pakietu
• Skopiuj plik .dSYM i .app do nowego katalogu
• cd do nowego reż
• Uruchom następujące polecenie: atos -arch armv7 -o 'Vimeo.app' / 'Vimeo'
• Terminal wejdzie w ruch interaktywny
• Wklej adres pamięci i naciśnij Enter, wyświetli nazwę metody i numer linii
• Możesz też wpisać to polecenie: atos -arch armv7 -o 'Vimeo.app' / 'Vimeo' Aby uzyskać informacje tylko dla jednego adresu

Połączenie, które działało dla mnie było:

1. Skopiuj plik dSYM do katalogu, w którym znajdował się raport o awarii
2. Rozpakuj plik IPA zawierający aplikację („Rozpakuj MyApp.ipa”)
3. Skopiuj plik binarny aplikacji z wynikowego ładunku wybuchowego do tego samego folderu, co raport o awarii i plik symboli (coś w rodzaju „MyApp.app/MyApp”)
4. Zaimportuj lub ponownie symbolizuj raport o awarii z poziomu organizatora Xcode

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.

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

212     my @executablePath = grep { -e && ! -d } glob("$dsymdir" . "/Contents/Resources/DWARF/" . $executable);

Wokół linii 265 w funkcji matchUUID

265             return 1;

Jest to proste, po wielu poszukiwaniach znalazłem wyraźne kroki, które symbolizują cały plik dziennika awarii.

• skopiuj pliki .app, crash_report i DSYM do folderu.
• podłącz urządzenie za pomocą xcode
• Następnie przejdź do okna -> wybierz urządzenia -> wyświetl dzienniki urządzeń
• Następnie wybierz to urządzenie, usuń wszystkie dzienniki.
• przeciągnij i upuść awarię w sekcji dziennika urządzenia. automatycznie symbolizuje awarię. kliknij raport prawym przyciskiem myszy i wyeksportuj go.

szczęśliwego kodowania,
Riyaz

Wolę skrypt, który będzie symbolizował wszystkie moje dzienniki awarii.

Warunki wstępne

Utwórz folder i umieść tam 4 rzeczy:

1. symbolicatecrash skrypt perl - istnieje wiele odpowiedzi SO, które mówią o jego lokalizacji

2. Archiwum kompilacji pasujące do awarii (z Xcode Organizer. Proste jak Show in Finderi skopiuj) [Nie wiem, czy to konieczne]

3. Wszystkie xccrashpointpakiety - (z Xcode Organizer. Show in FinderMożesz skopiować wszystkie pakiety z katalogu lub pojedynczy xccrashpoint, który chciałbyś symbolizować)

4. Dodaj ten krótki skrypt do katalogu:

   #!/bin/sh
   
   echo "cleaning old crashes from directory"
   rm -P *.crash
   rm -P *.xccrashpoint
   rm -r allCrashes
   echo "removed!"
   echo ""
   echo "--- START ---"
   echo ""
   
   mkdir allCrashes
   mkdir symboledCrashes
   find `ls -d *.xccrashpoint` -name "*.crash" -print -exec cp {} allCrashes/ \;
   
   cd allCrashes
   for crash in *.crash; do
       ../symbolicatecrash $crash > ../symboledCrashes/V$crash
   done
   cd ..
   
   echo ""
   echo "--- DONE ---"
   echo ""

Scenariusz

Po uruchomieniu skryptu otrzymasz 2 katalogi.

1. allCrashes- wszystkie awarie ze wszystkich xccrashpointbędą tam.

2. symboledCrashes - te same awarie, ale teraz wszystkie symbole.

3. NIE musisz usuwać katalogu ze starych awarii przed uruchomieniem skryptu. wyczyści się automatycznie. powodzenia!

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

• Git clone Repozytorium Symbolicator oraz kompiluj i uruchamiaj z Xcode
• Skopiuj plik .crash (plik ascii, ze śladami stosu na początku pliku) i .xarchive wydania awarii do tego samego folderu tymczasowego
• Przeciągnij i upuść plik .crash do ikony Symbolicator w Docku
• W 5-30 sekundach symboliczny plik awarii jest tworzony w tym samym folderze co .crash i .xarchive

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.

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:

#!/bin/bash
# Copy crash reports so that they appear in device logs in Organizer in Xcode

if [ ! -e ~/Downloads/crash ]; then 
   echo "Download a crash report and save it as $HOME/Downloads/crash before running this script."
   exit 1
fi

cd ~/Library/Logs/CrashReporter/MobileDevice/
mkdir -p actx # add crash report to xcode abbreviated
cd actx

datestr=`date "+%Y-%m-%d-%H%M%S"`

mv ~/Downloads/crash "actx-app_"$datestr"_actx.crash"

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):

header('Content-Disposition: attachment; filename="crash'.$timestamp.'.crash"');

Po drugie, w boku iOS w QuincyKit BWCrashReportTextFormatter.m ~ linii 176, zmiany @"[TODO]"do @"TODO"obejść złe znaki.

atos jest przestarzałe, więc jeśli używasz OSX 10.9 lub nowszego, może być konieczne uruchomienie

xcrun atos

Ostrzeżenie: / usr / bin / atos jest w ruchu i zostanie usunięty z przyszłej wersji OS X. Jest on teraz dostępny w narzędziach programistycznych Xcode, do których można wywoływać za pomocą:xcrun atos

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ą.

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.

...