App-crashes op de Mac zijn over het algemeen vrij zeldzaam. Maar wanneer ze gebeuren, wilt u misschien hun oorzaak achterhalen. En als u een ontwikkelaar bent, moet u begrijpen waarom uw app crasht. Hier leest u hoe u macOS-crashrapporten leest en de cryptische taal doorzoekt.

Crash-rapporten openen

Wanneer een app op uw Mac crasht, genereert deze automatisch een crashrapport. Je ziet dit na de crash verschijnen met een waarschuwingsvenster waarin staat dat " [App] onverwachts is gestopt. "Dat crashrapport is beschikbaar om meteen in dat venster te lezen door op de knop" Melden ... "te klikken. Het crashrapport is ook te vinden in de Console-app.

1. Open de Console-toepassing door "Console" in Spotlight in te voeren of door te navigeren naar "Toepassing -> Hulpprogramma's -> Console.app."

2. Klik op "Gebruikersrapporten" in het linkermenu en klik vervolgens op het crashrapport dat u wilt bekijken. Al deze bestanden eindigen in ".crash" en bevatten de datum en gecrashte applicatie in de titel. De details van het crashrapport zijn beschikbaar in het paneel aan de rechterkant.

Lezen van macOS-crashrapporten

Laten we het crashrapport van boven naar beneden navigeren.

Wat is er gecrasht?

Het eerste deel van het crashrapport vertelt u welk "proces" of toepassing is gecrasht. Het belangrijkste onderdeel voor de gemiddelde probleemoplosser is de procesnaam.

 Proces: aText [11473] Pad: /Applications/aText.app/Contents/MacOS/aText Identifier: com.trankynam.aText Versie: 2.19 (62) Type code: X86-64 (Native) Ouderproces: ??? [1] Verantwoordelijk: aText [11473] Gebruikers-ID: 501

Wanneer is het neergestort?

Het tweede deel vertelt ons wanneer de crash plaatsvond. Het biedt ook een beetje informatie over uw systeem.

 Datum / tijd: 2018-03-15 00: 58: 10.552 -0400 Besturingsversie: Mac OS X 10.12.6 (16G1036) Rapportversie: 12 Anoniem UUID: 6C985CFD-6975-3F30-50EB-0713315F5090 Tijd Ontwaakt sinds starten: 630000 seconden Systeemintegriteitsbescherming: ingeschakeld

Wat veroorzaakte de crash?

Het volgende deel is het meest verhelderend. Het "uitzonderingstype" dat door de toepassing wordt verstrekt, vertelt ons waardoor de crash is veroorzaakt. Het logboek meldt ook welke thread is gecrasht: in dit geval thread 0.

 Crashed Thread: 0 Verzendingswachtrij: com.apple.main-thread Uitzonderingstype: EXC_BAD_ACCESS (SIGSEGV) Uitzonderingscodes: KERN_INVALID_ADDRESS op 0x000040dedeadbec0 Uitzondering Opmerking: EXC_CORPSE_NOTIFY Beëindigingssignaal: Segmentatiefout: 11 Beëindiging Reden: naamruimte SIGNAAL, code 0xb Beëindigingsproces: exc handler [0]

Apple somt een aantal veelvoorkomende uitzonderingstypen op in hun technische documentatie:

  • Slechte geheugentoegang ( EXC_BAD_ACCESS / SIGSEGV / SIGBUS ) - het programma probeert onjuist toegang te krijgen tot het geheugen of met een ongeldig adres. Toegevoegd met een code die het geheugenprobleem verklaart.
  • Abnormal Exit ( EXC_CRASH / SIGABRT ) - abnormaal afsluiten, meestal bij een niet-afgevangen C ++ -uitzondering en aanroepen voor abort()
  • Trace Trap ( EXC_BREAKPOINT / SIGTRAP ) - zoals SIGABRT, maar deze exit geeft de bijgevoegde debugger de kans om het proces bij een breekpunt te onderbreken en de fout te traceren.
  • Ongeldige instructie ( EXC_BAD_INSTRUCTION / SIGILL ) - de verwerkte persoon heeft een instructie uitgegeven die niet werd begrepen of die niet kon worden verwerkt.
  • Stop ( SIGQUIT ) - het proces werd beëindigd door een ander proces met voldoende rechten. Doorgaans beëindigt een watchdog-proces een zich misdragend proces.
  • Killed ( SIGKILL ) - het proces werd beëindigd op verzoek van het systeem. Er wordt een beëindigingscode toegevoegd om de uitzondering te verklaren.

Zoals we kunnen zien in ons crashrapport, probeerde de toepassing toegang te krijgen tot niet-toegewezen geheugen. Dit is het gevolg van een programmeerfout in de toepassing of een ongewone gebruikersstatus, waardoor de toepassing het geheugen onjuist toewijst.

Wat leidde tot de crash?

Daarna zien we een omgekeerde chronologische lijst van wat tot de crash heeft geleid. Deze worden gesorteerd op thread, beginnend met thread 0.

Er zijn vier kolommen in dit rapport. De eerste rapporteert het nummer van de gebeurtenis in omgekeerde chronologische volgorde, beginnend bij 0. De tweede is de identificatie van het proces. De derde is het adres van het proces in het geheugen. De vierde is de naam van de taak van het programma.

Deze "backtrace" kan enigszins verbluffend zijn. Het is "symbolisch", wat betekent dat sommige geheugenadressen zijn vervangen door functienamen of applicatietaken. Soms kan dit niet volledig worden gedaan, waardoor onleesbare geheugenadressen verspreid over het rapport blijven.

We zien dit in het crashrapport hierboven: com.trankynam.aText is niet com.trankynam.aText . Zelfs met volledige symbolisatie kan het moeilijk zijn om de backtrace te lezen. Soms bevatten ontwikkelaars nuttige opmerkingen over applicatietaken en evenementen. Andere keren zijn het cryptische titels of numerieke code. Als je de symboliek kunt begrijpen, kun je misschien begrijpen wat er gebeurt. Maar het is net zo goed mogelijk dat je de applicatie zelf moet hebben gecodeerd om de backtrace te begrijpen.

Conclusie: is dit nuttig?

Als u een ontwikkelaar bent, is het lezen van crashmeldingen essentieel. Het helpt je te begrijpen welk deel van je applicatie crasht en waarom. Als u een gebruiker bent, zijn deze niet zo nuttig. Als u echter een blijvende crash ondervindt, kunnen de crashrapporten u helpen bij het oplossen van het probleem of samenwerken met de ontwikkelaar om het probleem op te lossen. Mogelijk ontvangt u een nuttige foutcode voor Google of kunt u technische ondersteuning bieden met de juiste informatie. Als je de bloederige details wilt, kun je er alles over lezen in de technische notitie van Apple over crashes.