App nedbrud på Mac er generelt temmelig sjældne. Men når de sker, vil du måske spore deres årsag. Og hvis du er en udvikler, skal du forstå, hvorfor din app kolliderer. Sådan læses macOS crash rapporter og sorterer gennem det krypterede sprog.

Åbning af Crash Reports

Når en app krasker på din Mac, genererer den automatisk en crash rapport. Du får se, at dette vises efter sammenbruddet med en advarselsdialog, der siger " [App] er afbrudt uventet. "Denne crash rapport er tilgængelig for at læse øjeblikkeligt i det vindue ved at klikke på knappen" Rapport ... ". Krasjerapporten kan også findes i konsolappen.

1. Åbn konsolprogrammet ved at skrive "Console" i Spotlight eller navigere til "Application -> Utilities -> Console.app."

2. Klik på "User Reports" i venstre menu, og klik derefter på den crash rapport, du vil se. Alle disse filer vil ende i ".crash" og inkludere datoen og nedbrudt applikationen i titlen. Oplysningerne om crash-rapporten er tilgængelige i ruden til højre.

Læsning af macOS Crash Reports

Lad os navigere i crash rapport fra top til bund.

Hvad styrtede?

Den første del af nedbrudsrapporten fortæller dig, hvilken "proces" eller applikationen styrtede. Den vigtigste del for den gennemsnitlige fejlfinding er procesnavnet.

 Process: aText [11473] Sti: /applikationer/aText.app/Contents/MacOS/aText Identifier: com.trankynam.aText Version: 2.19 (62) Kode Type: X86-64 (Modersmål) Forældreproces: ??? [1] Ansvarlig: aText [11473] Bruger ID: 501

Hvornår kollapsede det?

Den anden del fortæller os, hvornår nedbruddet opstod. Det giver også lidt information om dit system.

 Dato / Tid: 2018-03-15 00: 58: 10.552 -0400 OS Version: Mac OS X 10.12.6 (16G1036) Rapportversion: 12 Anonym UUID: 6C985CFD-6975-3F30-50EB-0713315F5090 Tid vågne siden start: 630000 sekunder System Integrity Protection: aktiveret

Hvad forårsagede nedbruddet?

Den næste del er den mest lysende. Den "undtagelsestype", der leveres af ansøgningen, fortæller os, hvad der forårsagede nedbruddet. Loggen rapporterer også, hvilken tråd der styrtede: i dette tilfælde tråd 0.

 Crashed Thread: 0 Dispatch kø: com.apple.main-thread Undtagelsestype: EXC_BAD_ACCESS (SIGSEGV) Undtagelseskoder: KERN_INVALID_ADDRESS ved 0x000040dedeadbec0 Undtagelses Bemærk: EXC_CORPSE_NOTIFY Afslutningssignal: Segmenteringsfejl: 11 Afslutningsårsag: Navnespace SIGNAL, kode 0xb Afslutningsproces: exc handler [0]

Apple lister nogle almindelige undtagelsestyper i deres tekniske dokumentation:

  • Adgang til dårlig hukommelse ( EXC_BAD_ACCESS / SIGSEGV / SIGBUS ) - Programmet forsøger at få adgang til hukommelsen forkert eller med en ugyldig adresse. Tilføjet med en kode, der forklarer hukommelsesproblemet.
  • Unormal exit ( EXC_CRASH / SIGABRT ) - unormal exit, typisk ved hjælp af en uncaught C ++-undtagelse og opfordrer til at abort()
  • Trace Trap ( EXC_BREAKPOINT / SIGTRAP ) - ligesom SIGABRT, men denne exit giver den vedlagte debugger chancen for at afbryde processen ved et breakpoint og spore fejlen.
  • Ulovlig instruktion ( EXC_BAD_INSTRUCTION / SIGILL ) - den behandlede udstedte en instruktion, som ikke blev forstået eller ikke kunne behandles.
  • Afslut ( SIGQUIT ) - processen blev afsluttet af en anden proces med tilstrækkelige privilegier. En watchdog-proces afsluttes typisk en misbehavende proces.
  • Dræbt ( SIGKILL ) - processen blev afsluttet efter anmodning fra systemet. En opsigelseskode vil blive vedlagt for at forklare undtagelsen.

Som vi kan se fra vores crash-rapport, forsøgte programmet at få adgang til ikke-mappede hukommelser. Dette skyldes en programmeringsfejl i applikationen eller en usædvanlig brugerstatus, der får applikationen til at kortlægge hukommelsen forkert.

Hvad fører til ulykken?

Herefter ser vi en omvendt kronologisk liste over, hvad der fører op til nedbruddet. Disse sorteres efter tråd, begyndende med tråd 0.

Der er fire kolonner til denne rapport. Den første rapporterer begivenhedens nummer i omvendt kronologisk rækkefølge, begynder ved 0. Den anden er procesens identifikator. Den tredje er adressen til processen i hukommelsen. Den fjerde er navnet på programmets opgave.

Denne "backtrace" kan være lidt forvirrende. Det er "symboliseret", hvilket betyder at nogle af hukommelsesadresserne er blevet erstattet med funktionsnavne eller applikationsopgaver. Nogle gange kan dette ikke gøres fuldstændigt, hvilket efterlader ulæselige hukommelsesadresser spredt gennem rapporten.

Vi ser dette i com.trankynam.aText ovenfor: com.trankynam.aText er ikke symboliseret. Selv med fuldstændig symbolisering kan det være svært at læse backtracket. Nogle gange indeholder udviklere nyttige noter om applikationsopgaver og begivenheder. Andre gange er de krypterede titler eller numeriske kode. Hvis du kan give mening om symboliseringen, kan du måske forstå, hvad der sker. Men det er lige så muligt, at du bliver nødt til at have kodet applikationen selv for at give mening om backtrace.

Konklusion: Er dette nyttigt?

Hvis du er en udvikler, er det vigtigt at læse nedbrudsrapporter. Det hjælper dig med at forstå, hvilken del af din ansøgning der styrter og hvorfor. Hvis du er en bruger, er de ikke så hjælpsomme. Men hvis du har et vedvarende crash, kan crashrapporterne hjælpe dig med at fejle problemet eller arbejde med udvikleren for at løse problemet. Du kan muligvis få en nyttig fejlkode til Google eller være i stand til at levere teknisk support med de rigtige oplysninger. Hvis du vil have gory detaljerne, kan du læse alt om det i Apples tekniske note om nedbrud.