Dzienniki awarii generowane przez iPhone Simulator?

Czy są jakieś dzienniki awarii generowane przez iPhone Simulator?

Symulator dużo się zawiesza, ale nie pozostawia żadnych śladów w Konsoli ... Dziennik awarii będzie przydatny.

Konsola pokaże dane NSLog()wyjściowe z aplikacji uruchomionej w symulatorze. Dzienniki awarii są zapisywane w pliku.

Znalazłem kilka w moim katalogu domowym pod

~/Library/Logs/DiagnosticReports/

Mają rozszerzenie pliku .crash

Coś, czego jeszcze nie odkryłem, to jak zmusić je do wygenerowania, nawet jeśli debugger przechwyci EXC_BAD_ACCESSsygnał.

Aktualizacja

Obecnie (OSX 10.11.6) .crash loguje się ~/Library/Logs/DiagnosticReports, gdy sam emulator ulega awarii . Dzienniki awarii aplikacji (ale urządzenie emulatora nadal działa poprawnie) znajdują się w:

~ / Library / Logs / CoreSimulator

W przypadku każdej awarii istnieje podfolder z unikalnym identyfikatorem. Sortuj według daty, tak aby ostatnia awaria była pierwszym podfolderem. Wewnątrz zacznij od spojrzenia na stderr.logi system.log.

Również bezpośrednio pod CoreSimulator, patrz CoreSimulator.logi Simulator.log.

Jestem prawie pewien, że widać to w aplikacji OS X Console znajdującej się w Utilities. Jeśli się mylę, pamiętaj, aby zagłosować na mnie, więc usunę to.

AKTUALIZACJA:

W szczególności (od OSX 10.11.6),

Kiedy aplikacja ulega awarii na emulatorze, podfolder (z unikalnym identyfikatorem) jest dodawany do:

~ / Library / Logs / CoreSimulator

W ramach tego zacznij od zbadania stderr.logi system.log.

Kiedy sam emulator ulega awarii, podfolder jest dodawany do:

~ / Library / Logs / DiagnosticReports

Nie myl tej ścieżki z

/ Library / Logs

(brak ~na początku), który zawiera różne raporty na temat twojego komputera Mac.

Oto coś, co zadziałało w moim przypadku w szczególnym przypadku ... Moja aplikacja ulegała awarii z SIGKILL podczas zamykania. Widziałbym wyjątek w main.m przez kilka sekund, a następnie aplikacja kończyłaby pracę - w ten sposób nie ma szans na uzyskanie wstecznego śledzenia.

Dużo szukałem informacji „gdzie symulator przechowuje swoje dzienniki awarii” i nigdy nie udało mi się znaleźć odpowiedzi. Jednak następująca sztuczka okazała się całkiem przydatna i mogłem pobrać dziennik awarii w locie:

Zasadniczo otwórz /Applications/Utilities/CrashReporterPrefs.app i zmień ustawienie na „Developer”. Spowoduje to, że CrashReporter wyświetli wyskakujące okienko z dziennikiem awarii po awarii aplikacji.

Znalazłem to w sekcji „Wyświetlanie konsoli symulatora iOS i dzienników awarii” w tym dokumencie firmy Apple: http://developer.apple.com/library/ios/#documentation/Xcode/Conceptual/ios_development_workflow/125-Using_iOS_Simulator/ios_simulator_application. html

Jest to znacznie bardziej niezawodne. W zaledwie kilku krokach udało mi się znaleźć numer linii źródłowej i nazwę metody:

1. cd do katalogu zawierającego pliki .app i .dSYM
2. run /Developer/Platforms/iPhoneOS.platform/Developer/usr/libexec/gdb/gdb-arm-apple-darwin MyApp.app/MyApp
3. włącz print asm-demangle
4. włącz opcję drukowania nazwy pliku z symbolem
5. p / a 0 × 00015c64 -> adres uzyskany po otwarciu dziennika awarii w aplikacji „Konsola” lub po dwukrotnym kliknięciu pliku .crash.

Dzienniki awarii pojawią się w ~ / Library / Logs / CrashReporter.

• Jeśli program symulatora iPhone'a ulegnie awarii (a nie aplikacja iPhone działająca w symulatorze), pojawi się wpis dla iPhoneSimulator.
• Jeśli aplikacja iPhone w symulatorze ulegnie awarii, dziennik awarii zostanie wyświetlony z wyświetlaną nazwą aplikacji.

Gdy Xcode pobiera dzienniki awarii z podłączonego urządzenia, przechowuje je w podfolderach ~ / Library / Logs / CrashReporter / MobileDevice

Dla mnie było to wyrażenie, które dodałem do okna obserwacyjnego debugera. Kiedy punkt przerwania był trafiony, złe wyrażenie powodowało segfault XCode.