App krasjer på Mac er vanligvis ganske sjeldne. Men når de skjer, vil du kanskje spore deres sak. Og hvis du er utvikler, må du forstå hvorfor appen din krasjer. Slik leser du macOS-krasjrapporter og sorterer gjennom kryptisk språk.

Åpning av krasjrapporter

Når en app krasjer på din Mac, genererer den automatisk en krasjrapport. Du får se at dette vises etter krasj med en advarselsdialog som sier " [App] er avsluttet uventet. "Den krasjrapporten er tilgjengelig for å lese umiddelbart i det vinduet ved å klikke på" Rapporter ... "-knappen. Krasjrapporten kan også bli funnet i konsoll-appen.

1. Åpne konsollprogrammet ved å skrive "Console" i Spotlight eller navigere til "Application -> Utilities -> Console.app."

2. Klikk på "User Reports" i venstre meny, og klikk deretter på krasjrapporten du vil vise. Alle disse filene vil ende i ".crash" og inkludere datoen og krasjet programmet i tittelen. Detaljer om krasjrapporten er tilgjengelige i ruten til høyre.

Leser macOS Crash Reports

La oss navigere i krasjrapporten fra topp til bunn.

Hva krasjet?

Den første delen av krasjrapporten forteller deg hva "prosess" eller program krasjet. Den viktigste delen for gjennomsnittlig feilsøking er prosessnavnet.

 Prosess: aText [11473] Sti: /applikasjoner/aText.app/Contents/MacOS/aText Identifier: com.trankynam.aText Versjon: 2.19 (62) Kode Type: X86-64 (Native) Foreldreprosess: ??? [1] Ansvarlig: aText [11473] Bruker-ID: 501

Når krasjet det?

Den andre delen forteller oss når krasjen skjedde. Det gir også litt informasjon om systemet ditt.

 Dato / klokkeslett: 2018-03-15 00: 58: 10.552 -0400 OS Versjon: Mac OS X 10.12.6 (16G1036) Rapportversjon: 12 Anonym UUID: 6C985CFD-6975-3F30-50EB-0713315F5090 Tid oppvåst siden oppstart: 630000 sekunder System Integrity Protection: aktivert

Hva forårsaket krasj?

Den neste delen er den mest opplysende. Den "unntakstype" som er gitt av søknaden forteller oss hva som forårsaket krasj. Loggen rapporterer også hvilken tråd som krasjet: i dette tilfellet tråden 0.

 Crashed Thread: 0 Dispatch kø: com.apple.main-thread Unntakstype: EXC_BAD_ACCESS (SIGSEGV) Unntakskoder: KERN_INVALID_ADDRESS på 0x000040dedeadbec0 Unntak Note: EXC_CORPSE_NOTIFY Oppsigelsessignal: Segmenteringsfeil: 11 Oppsigelsesårsak: Navnspace SIGNAL, Code 0xb Avsluttingsprosess: exc handler [0]

Apple viser noen vanlige unntakstyper i deres tekniske dokumentasjon:

  • Dårlig minnetilgang ( EXC_BAD_ACCESS / SIGSEGV / SIGBUS ) - Programmet forsøker å få tilgang til minnet feil eller med en ugyldig adresse. Vedlagt med en kode som forklarer minnesproblemet.
  • Unormal exit ( EXC_CRASH / SIGABRT ) - unormal utgang, vanligvis ved hjelp av et uncaught C ++-unntak og anrop for å abort()
  • Trace Trap ( EXC_BREAKPOINT / SIGTRAP ) - som SIGABRT, men denne avslutningen gir den vedlagte debuggeren sjansen til å avbryte prosessen ved et bruddpunkt og spore feilen.
  • Ulovlig instruksjon ( EXC_BAD_INSTRUCTION / SIGILL ) - den behandlede utstedte en instruksjon som ikke ble forstått eller ikke kunne behandles.
  • Avslutt ( SIGQUIT ) - prosessen ble avsluttet av en annen prosess med tilstrekkelige privilegier. Vanligvis avslutter en vaktprosess en feilbehandlingsprosess.
  • Dødt ( SIGKILL ) - prosessen ble avsluttet på forespørsel fra systemet. En oppsigelseskode vil bli vedlagt for å forklare unntaket.

Som vi kan se fra vår krasjapport, forsøkte programmet å få tilgang til det ikke-mappede minnet. Dette skyldes en programmeringsfeil i applikasjonen eller en uvanlig brukerstatus som forårsaker at programmet ikke kartlegger minnet feil.

Hva fører til krasj?

Deretter ser vi en omvendt kronologisk liste over hva som fører opp til krasj. Disse er sortert etter tråd, begynner med tråd 0.

Det er fire kolonner til denne rapporten. Den første rapporterer hendelsens nummer i omvendt kronologisk rekkefølge, starter ved 0. Den andre er prosessens identifikator. Den tredje er adressen til prosessen i minnet. Den fjerde er navnet på programmets oppgave.

Denne "backtrace" kan være litt forvirrende. Det er "symbolisert", noe som betyr at noen av minnesadressene er erstattet med funksjonsnavn eller applikasjonsoppgaver. Noen ganger kan dette ikke gjøres helt, og lar ulæselige minnesadresser spredt gjennom rapporten.

Vi ser dette i krasjrapporten ovenfor: com.trankynam.aText er ikke symbolisert. Selv med fullstendig symbolisering kan det være vanskelig å lese backtrace. Noen ganger inneholder utviklere nyttige notater om programoppgaver og hendelser. Andre ganger er de krypterte titler eller numerisk kode. Hvis du kan gi mening om symbolisering, kan du kanskje forstå hva som skjer. Men det er like mulig at du må ha kodet applikasjonen selv for å gi mening om backtrace.

Konklusjon: Er dette nyttig?

Hvis du er utvikler, er det viktig å lese krasjrapporter. Det hjelper deg å forstå hvilken del av søknaden din krasjer og hvorfor. Hvis du er en bruker, er de ikke så nyttige. Men hvis du har en vedvarende krasj, kan krasjrapporter hjelpe deg med å feilsøke problemet eller jobbe med utvikleren for å fikse problemet. Du kan få en nyttig feilkode til Google, eller kunne gi teknisk støtte med riktig informasjon. Hvis du vil ha gory detaljer, kan du lese alt om det i Apples tekniske notat om krasjer.