Awarie aplikacji na komputerze Mac zdarzają się dość rzadko. Ale gdy już się zdarzają, warto zbadać przyczynę tych problemów. A jeśli jesteś programistą, musisz zrozumieć przyczynę awarii swojej aplikacji. Oto jak czytać raporty o awariach w systemie macOS i rozszyfrować zawiły język.
Szybkie linki
Otwórz raporty o awariach
Gdy aplikacja ulegnie awarii na komputerze Mac, automatycznie generuje raport o awarii. Pojawi się on po awarii wraz z ostrzeżeniem: „[Aplikacja] nieoczekiwanie się zatrzymała”. Raport o awarii można natychmiast wyświetlić w tym oknie, klikając przycisk „Zgłoś…”. Raport o awarii można również znaleźć w aplikacji Konsola.
1. Otwórz aplikację Konsola, wpisując „Konsola” w Spotlight lub przejdź do „Aplikacje -> Narzędzia -> Console.app”.
2. Kliknij „Raporty użytkowników” w menu po lewej stronie, a następnie kliknij raport o awarii, który chcesz wyświetlić. Wszystkie te pliki kończą się rozszerzeniem „.crash” i zawierają datę oraz nazwę aplikacji, która uległa awarii w tytule. Szczegóły raportu o awarii są dostępne w panelu po prawej stronie.
Przeczytaj raporty o awariach systemu Mac OS
Przyjrzyjmy się raportowi o awarii od góry do dołu.
Co jest zepsute?
Pierwsza część raportu o awarii informuje, czy proces lub aplikacja uległy awarii. Najważniejsza dla narzędzia do rozwiązywania problemów jest nazwa procesu.
Proces: aText [11473] Ścieżka: /Applications/aText.app/Contents/MacOS/aText Identyfikator: com.trankynam.aText Wersja: 2.19 (62) Typ kodu: X86-64 (natywny) Proces nadrzędny: ??? [1] Odpowiedzialny: aText [11473] Identyfikator użytkownika: 501
Kiedy nastąpiła awaria?
Druga część informuje nas, kiedy wystąpiła awaria. Zawiera również pewne informacje o systemie.
Data/Czas: 2018-03-15 00:58:10.552 -0400 Wersja systemu operacyjnego: Mac OS 630000 sekund Ochrona integralności systemu: włączona
Co było przyczyną awarii?
Kolejna część jest najbardziej pouczająca. „Typ wyjątku” zgłaszany przez aplikację wskazuje przyczynę awarii. Dziennik informuje również, w którym wątku wystąpiła awaria: w tym przypadku jest to wątek 0.
Wątek, który uległ awarii: 0 Kolejka wysyłkowa: com.apple.main-thread Typ wyjątku: EXC_BAD_ACCESS (SIGSEGV) Kody wyjątków: KERN_INVALID_ADDRESS pod adresem 0x000040dedeadbec0 Uwaga dotycząca wyjątku: EXC_CORPSE_NOTIFY Sygnał zakończenia: Błąd segmentacji: 11 Przyczyna zakończenia: SYGNAŁ przestrzeni nazw, kod 0xb Proces kończący: exc handler [0]
Listy Apple Niektóre typowe typy wyjątków W swoich dokumentach technicznych:
Błędny dostęp do pamięci (EXC_BAD_ACCESS / SIGSEGV / SIGBUS) – program próbuje uzyskać dostęp do pamięci nieprawidłowo lub używając nieprawidłowego adresu. Ten kod wyjaśnia problem z pamięcią.
Nieprawidłowe wyjście (EXC_CRASH / SIGABRT) – nieprawidłowe wyjście, zwykle spowodowane nieprzechwyconym wyjątkiem C++ i wywołaniem funkcji abort()
Pułapka śledzenia (EXC_BREAKPOINT / SIGTRAP) – podobna do SIGABRT, ale to zakończenie daje dołączonemu debuggerowi możliwość przerwania procesu w punkcie przerwania i śledzenia błędu.
Nielegalna instrukcja (EXC_BAD_INSTRUCTION / SIGILL) – proces wydał instrukcję, która nie została zrozumiana lub nie mogła zostać przetworzona.
Quit (SIGQUIT) – Proces został zakończony przez inny proces z odpowiednimi uprawnieniami. Zazwyczaj proces monitorujący kończy działanie procesu, który się nieprawidłowo zachowuje.
Zakończ (SIGKILL) – Proces został zakończony na żądanie systemu. Dodany zostanie kod wyjścia wyjaśniający wyjątek.
Jak wynika z raportu awarii, aplikacja próbowała uzyskać dostęp do nieprzydzielonej pamięci. Było to spowodowane błędem programistycznym w aplikacji lub nietypowym zachowaniem użytkownika, które spowodowało, że aplikacja nieprawidłowo przydzieliła pamięć.
Co jest przyczyną usterki?
Następnie widzimy listę odwrotnej chronologii, która zawiera przyczyny awarii. Lista jest posortowana według wątku, zaczynając od wątku 0.
Raport składa się z czterech kolumn. Pierwsza kolumna zawiera numer zdarzenia w odwrotnej kolejności chronologicznej, zaczynając od 0. Druga kolumna zawiera identyfikator procesu. Trzecia kolumna zawiera adres procesu w pamięci. Czwarta kolumna zawiera nazwę zadania programu.
To „wycofanie” może być nieco mylące. Ma ono charakter „symboliczny”, co oznacza, że niektóre adresy pamięci zostały zastąpione nazwami funkcji lub zadaniami aplikacji. Czasami nie da się tego zrobić całkowicie, przez co adresy pamięci pozostają nieczytelne i rozproszone po całym raporcie.
Widzimy to w powyższym raporcie o awarii: com.trankynam.aText nie jest symboliczny. Nawet przy pełnym kodzie symbolicznym, ślad wsteczny może być trudny do odczytania. Czasami programiści dołączają pomocne uwagi dotyczące zadań i zdarzeń aplikacji. Innym razem są to zagadkowe adresy lub kod numeryczny. Jeśli rozumiesz kod symboliczny, możesz zrozumieć, co się dzieje. Jednak w miarę możliwości musisz samodzielnie napisać kod aplikacji, aby zrozumieć ślad wsteczny.
Podsumowanie: Czy to jest pomocne?
Jeśli jesteś programistą, czytanie raportów o awariach jest niezbędne. Pomagają one zrozumieć, która część aplikacji powoduje problemy i dlaczego. Jeśli jesteś użytkownikiem, nie są one pomocne. Jeśli jednak awarie powtarzają się, raporty o awariach mogą pomóc Ci je rozwiązać lub skontaktować się z programistą w celu ich rozwiązania. Możesz otrzymać pomocne rozwiązanie w postaci kodu błędu od Google lub przesłać je do pomocy technicznej wraz z poprawnymi informacjami. Jeśli chcesz poznać szczegółowe informacje, przeczytaj artykuł. Notatka techniczna Apple dotycząca awarii.
