Appkrascher på Mac är vanligtvis ganska sällsynta. Men när de händer kanske du vill spåra deras sak. Och om du är en utvecklare måste du förstå varför din app kraschar. Så här läser du macOS-kraschrapporter och sorterar igenom kryptiskt språk.

Öppna kraschrapporter

När en app kraschar på din Mac genererar den automatiskt en kraschrapport. Du ser att detta visas efter kraschen med en varningsdialog som säger " [App] har slutat oväntat. "Den här kraschrapporten är tillgänglig för att läsa omedelbart i det här fönstret genom att klicka på" Report ... "-knappen. Kraschrapporten finns också i konsolappen.

1. Öppna konsolprogrammet genom att skriva "Console" i Spotlight eller navigera till "Application -> Utilities -> Console.app."

2. Klicka på "Användarrapporter" i menyn till vänster och klicka sedan på kraschrapporten du vill visa. Alla dessa filer hamnar i ".crash" och inkluderar datumet och kraschade programmet i titeln. Detaljerna i kraschrapporten finns i rutan till höger.

Läser macOS Crash Reports

Låt oss navigera kraschrapporten från topp till botten.

Vad kraschade?

Den första delen av kraschrapporten berättar vilken "process" eller applikation som kraschades. Den viktigaste delen för den genomsnittliga felsökaren är processnamnet.

 Process: aText [11473] Path: /Applications/aText.app/Contents/MacOS/aText Identifier: com.trankynam.aText Version: 2.19 (62) Kodtyp: X86-64 (Modersmål) Föräldraprocess: ??? [1] Ansvarig: aText [11473] Användar-ID: 501

När kraschar det?

Den andra delen berättar när kraschen inträffade. Det ger också lite information om ditt system.

 Datum / 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 Uppvaknare Sedan Boot: 630000 sekunder System Integrity Protection: enabled

Vad orsakade kraschen?

Nästa del är den mest upplysande. Den "undantagstyp" som tillhandahålls av ansökan berättar om vad som orsakade kraschen. Loggen rapporterar också vilken tråd som kraschade: i det här fallet tråd 0.

 Crashed Thread: 0 Dispatch kö: com.apple.main-thread Undantagstyp: EXC_BAD_ACCESS (SIGSEGV) Undantagskoder: KERN_INVALID_ADDRESS vid 0x000040dedeadbec0 Undantag Obs: EXC_CORPSE_NOTIFY Avslutningssignal: Segmenteringsfel: 11 Avslutningsskäl: Namnrymd SIGNAL, kod 0xb Avslutande process: exc handler [0]

Apple listar några vanliga undantagstyper i sin tekniska dokumentation:

  • Dålig EXC_BAD_ACCESS ( EXC_BAD_ACCESS / SIGSEGV / SIGBUS ) - Programmet försöker få åtkomst till minnet felaktigt eller med en ogiltig adress. Bifogas med en kod som förklarar minnesproblemet.
  • Onormal utgång ( EXC_CRASH / SIGABRT ) - onormal utträde, vanligtvis med hjälp av ett obestämt C ++-undantag och samtal för att abort()
  • Trace Trap ( EXC_BREAKPOINT / SIGTRAP ) - som SIGABRT, men den här avslutningen ger den bifogade debugger chansen att avbryta processen vid en brytpunkt och spåra felet.
  • Illegal Instruction ( EXC_BAD_INSTRUCTION / SIGILL ) - den bearbetade utfärdat en instruktion som inte förstod eller kunde inte behandlas.
  • Avsluta ( SIGQUIT ) - processen avslutades med en annan process med tillräckliga privilegier. En watchdog-process avslutar vanligtvis en misshandlingsprocess.
  • Dödad ( SIGKILL ) - processen avslutades på begäran av systemet. En termineringskod kommer att läggas till för att förklara undantaget.

Som vi kan se från vår kraschrapport försökte programmet få åtkomst till omappat minne. Detta beror på ett programmeringsfel i programmet eller ett ovanligt användarläge som orsakar att programmet kartlägger minnet felaktigt.

Vad leder till kraschen?

Därefter ser vi en omvänd kronologisk lista över vad som leder till kraschen. Dessa sorteras efter tråd, börjar med tråd 0.

Det finns fyra kolumner till denna rapport. Den första rapporterar händelsens nummer i omvänd kronologisk ordning, börjar vid 0. Den andra är processens identifierare. Den tredje är adressen till processen i minnet. Den fjärde är namnet på programmets uppgift.

Denna "backtrace" kan vara något förbryllande. Det är "symboliserat", vilket innebär att några av minnesadresserna har ersatts med funktionsnamn eller applikationsuppgifter. Ibland kan det inte göras fullständigt, vilket leder till oläsliga minnesadresser spridda genom rapporten.

Vi ser detta i com.trankynam.aText ovan: com.trankynam.aText är inte symboliserad. Även med fullständig symbolisering kan det vara svårt att läsa backtrace. Ibland innehåller utvecklarna användbara noteringar om applikationsuppgifter och händelser. Andra gånger är de krypterande titlar eller numerisk kod. Om du kan känna av symbolisering kan du kanske förstå vad som händer. Men det är lika mycket som möjligt att du måste ha kodat ansökan själv för att göra känslan av backtrace.

Slutsats: Är detta användbart?

Om du är en utvecklare är läsning av kraschrapporter avgörande. Det hjälper dig att förstå vilken del av din ansökan som kraschar och varför. Om du är en användare är de inte så hjälpsamma. Men om du har en ihållande krasch kan kraschrapporterna hjälpa dig att felsöka problemet eller arbeta med utvecklaren för att åtgärda problemet. Du kan få en användbar felkod till Google eller kunna ge teknisk support med rätt information. Om du vill ha gory detaljer, kan du läsa allt om det i Apples tekniska anteckning om kraschar.