Symbol X Crash Log Symbolication

Nie mogę oznaczyć logów awarii systemu OS X (nie iOS) od testerów i użytkowników korzystających z XCode 4.6. Dzienników awarii nie można przeciągać do organizatora, a organizator nie wyświetla żadnych dzienników awarii z katalogu ~/Library/Logs/DiagnosticReports /, ale niektóre dzienniki znajdują się w tym katalogu.Symbol X Crash Log Symbolication

Didier Malenfant skomentował poprzedniego wątku XCode not importing OS X crash log że

Najważniejsze jest to całkiem proste. Od tej pory (Xcode 4.6), logi awarii OS X nie mogą być importowane do Xcode. Tylko te iOS.

Czy to jest obecny stan rzeczy? Trudno sobie wyobrazić, że organizacje są w stanie obsługiwać nowe oprogramowanie OS X bez skutecznych sposobów na intepretowanie raportów o awariach.

Źródło

2013-07-05 Mark Bernstein

zobaczyć http://stackoverflow.com/questions/6085734/how-do-i-symbolicate-a-crash-report-of-a-mac-os-x-app-that-a-user-emailed-to-me –

Dzięki. Ale odpowiedź, którą cytujesz, jest ponad rok starsza niż odpowiedź, którą przytoczyłem powyżej, co jest sprzeczne z nią. Czy rutynowo symbolizujesz przesłane przez użytkowników logi w kodzie Xcode 4.6? –

Można użyć GDB do Symbolication, połóż kompilacji uwolnienia i plik .dSYM w tym samym katalogu otwartego terminala

$ cd directory 
$ gdb MyApp.app 
(gdb) info line *0x00085f3c

lub użyć atos jak sugeruje trojanfoe

$cd directory 
$atos -o MyApp.app/Contents/MacOS/MyApp 
info 0x00085f3c

lub

$ cd directory 
$ lldb MyApp.app 
(lldb) image lookup -v --address 0x1ec4

Źródło

2013-08-21 09:44:41

Lub 'atos': https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/atos.1.html – trojanfoe

@trojanfoe Zaktualizowano. –

Lub 'lldb' :)' lookup -v --address 0x1ec4' – trojanfoe

Jeśli masz ślad stosu; na przykład:

0 com.your_app  0x00000001016191e0 0x1015fb000 + 123360 
1 com.your_app  0x000000010161509d 0x1015fb000 + 106653 
2 com.your_app  0x00000001016147b9 0x1015fb000 + 104377 
3 com.your_app  0x000000010161df81 0x1015fb000 + 143233`

Spróbuj wykonać następujące czynności:

atos -o YOUR_APP.app.dSYM/Contents/Resources/DWARF/YOUR_APP -l 0x1015fb000 0x00000001016191e0 0x000000010161509d 0x00000001016147b9 0x000000010161df81`

Źródło

2014-04-19 19:13:15 w00t

Mieliśmy ten sam problem z naszej aplikacji i byłem symbolicating raporty o awariach ręcznie linia po linii z atos.

Teraz zmodyfikowałem skrypt symboliczny Apple tak, aby działał z aplikacjami Mac i raportami o awariach z PLCrashReporter.

https://github.com/lksnmnn/Symbolicate-CrashReports

Jak go używać:

Sprawdź, czy masz wszystko na komputerze następujące pliki:

Raport awarii: report.crash
Plik dSYM Twojej aplikacji: MyApp.dSYM
Folder plików wykonywalnych/aplikacji: MyApp.Aplikacja
Ulepszony skrypt symbolicate: symbolicatecrash

Teraz przejdź w wierszu poleceń (terminal) i wykonaj następujące czynności:

# set the developer directory 
export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer" 

# Now run the script 
/Path/To/symbolicatecrash /Path/To/report.crash > /Path/To/readable_report.crash 

# Use -v for verbose logging.

Skrypt znajdzie swój dSYM i swój plik wykonywalny i symbolizuje tyle, ile może puszek. Będziesz teraz znaleźć symbolicated raportu w podanym pliku wyjściowego readable_report.crash

ustawień produkcji:

Do odpowiednich raportów i symboli, ustawić ustawienia kompilacji do tego:

Strip Debug Symbols During Copy: Yes 
Strip Style: All Symbols 
Strip Linked Product: Yes

Źródło

2016-02-26 11:59:50

Odpowiedz

Powiązane problemy