Meestal is het zeer zeldzaam dat apps op een Mac crashen. Maar als dat gebeurt, wilt u misschien deze problemen bijhouden. En als u een ontwikkelaar bent, moet u begrijpen waarom uw app crasht. Hier leest u hoe u macOS-crashrapporten kunt lezen en sorteren op gecodeerde taal.
Crashrapporten openen
Wanneer een app crasht op je Mac, genereert deze automatisch een crashrapport. Je ziet dit verschijnen na de crash met een waarschuwingsvenster met de melding "[Applicatie] is onverwacht gestopt." Dit crashrapport kan direct in dit venster worden gelezen door op de knop "Rapporteren..." te klikken. Het crashrapport is ook te vinden in de Console-app.
1. Open de Console-app door "Console" in Spotlight te typen of ga 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 op ".crash" en bevatten de datum en kapotte app in de titel. Details van het crashrapport zijn beschikbaar in het rechterdeelvenster.
Mac OS-crashrapporten lezen
Laten we het crashrapport van boven naar beneden doornemen.
Wat is het dat crasht?
Het eerste deel van het crashrapport laat u zien of een proces of toepassing het "crasht". Het belangrijkste onderdeel voor een probleemoplosser is de naam van het proces.
Process: aText [11473] Path: /Applications/aText.app/Contents/MacOS/aText Identifier: com.trankynam.aText Version: 2.19 (62) Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: aText [11473] User ID: 501
Wanneer zijn de feestdagen geweest?
Het tweede deel vertelt ons wanneer de fout is opgetreden. Het geeft ook een beetje informatie over uw systeem.
Date/Time: 2018-03-15 00:58:10.552 -0400 OS Version: Mac OS X 10.12.6 (16G1036) Report Version: 12 Anonymous UUID: 6C985CFD-6975-3F30-50EB-0713315F5090 Time Awake Since Boot: 630000 seconds System Integrity Protection: enabled
Wat veroorzaakte de storing?
Het volgende deel is het meest verhelderend. Het 'Uitzonderingstype' dat door de app wordt aangeboden, vertelt ons wat de storing heeft veroorzaakt. Het logboek meldt ook welke thread is gecrasht: in dit geval thread 0.
Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x000040dedeadbec0 Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler [0]
Apple-lijsten Enkele veelvoorkomende soorten uitzonderingen In de technische documentatie:
Slechte geheugentoegang (EXC_BAD_ACCESS / SIGSEGV / SIGBUS) – Het programma probeert onjuist of met een ongeldig adres toegang te krijgen tot het geheugen. Met een code die het geheugenprobleem verklaart.
Abnormale exit (EXC_CRASH / SIGABRT) - Abnormale exit, meestal door een C++ niet-opgeschorte uitzondering en een oproep tot abort()
Trace Trap (EXC_BREAKPOINT / SIGTRAP) - Hetzelfde als SIGABRT, maar deze beëindiging geeft de bijgevoegde debugger de mogelijkheid om het proces op een breekpunt te onderbreken en de fout te traceren.
Illegale instructies (EXC_BAD_INSTRUCTION / SIGILL) – Verwerking heeft een verwerking uitgegeven die niet werd begrepen of niet kon worden verwerkt.
Afsluiten (SIGQUIT) – Het proces is beëindigd door een ander proces met voldoende bevoegdheden. Meestal beëindigt het monitoringproces het proces van wanpraktijken.
Beëindigen (SIGKILL) - Het proces is beëindigd op verzoek van het systeem. Er wordt een exit-code toegevoegd om de uitzondering uit te leggen.
Zoals we kunnen zien in het crashrapport, probeerde de applicatie toegang te krijgen tot het niet-quarantainegeheugen. Dit komt door een programmeerfout in de applicatie of een ongebruikelijke gebruikersconditie waardoor de applicatie het geheugen onjuist toewijst.
Wat leidt tot storingen?
Vervolgens zien we een omgekeerd chronologische lijst van wat de crash veroorzaakt. Deze zijn gesorteerd op thread, te beginnen met thread 0.
Dit rapport bestaat uit vier kolommen. De eerste rapporteert het gebeurtenisnummer in omgekeerde chronologische volgorde, te beginnen met 0. De tweede is de proces-ID. De derde is het adres van het proces in het geheugen. De vierde is de naam van de taak van het programma.
Dit "ongedaan maken" kan enigszins verbijsterend zijn. Ze zijn "symbolisch", wat betekent dat sommige geheugenadressen zijn vervangen door de namen van functies of applicatietaken. Soms kan dit niet volledig worden gedaan, waardoor onleesbare geheugenadressen bezaaid blijven met het rapport.
We zien dit in het crashrapport hierboven: com.trankynam.aText is niet-token. Zelfs met volledige codering kan de achtergrond moeilijk te lezen zijn. Softwareontwikkelaars voegen soms nuttige opmerkingen toe over toepassingstaken en gebeurtenissen. Andere keren zijn het versleutelde adressen of een numerieke code. Als je de symboliek kunt begrijpen, kun je misschien ook begrijpen wat er aan de hand is. Maar je moet de applicatie zoveel mogelijk zelf coderen om de backtrace te begrijpen.
Conclusie: is dit nuttig?
Als u een softwareontwikkelaar bent, is het essentieel om de crashrapporten te lezen. Dit helpt u te begrijpen welk deel van uw app problemen veroorzaakt en waarom. Als u een gebruiker bent, zijn ze niet nuttig. Maar als u constant crasht, kunnen crashrapporten u helpen het probleem op te lossen of samen met de ontwikkelaar het probleem op te lossen. U kunt de foutcode op een nuttige manier via Google laten oplossen of u kunt deze met de juiste informatie indienen bij de technische ondersteuning. Als je drastische details wilt, kun je er alles over lezen op Technische opmerking van Apple over crashes.
