Finder stopt onverwacht. Maar waarom?
Crashrapporten kunnen aanwijzingen geven waarom een app is gecrasht in macOS. Hier leest u hoe u kunt begrijpen wat die rapporten eigenlijk zeggen over uw Mac.
Je hebt waarschijnlijk een Finder-waarschuwing gezien wanneer een app stopt onverwacht op je Mac.
In de programmeerwereld bekend als een”crash”, treden deze fouten meestal op wanneer een slecht stuk code wordt uitgevoerd dat het systeem of de CPU niet kan uitvoeren. Ze kunnen ook optreden als een app toegang probeert te krijgen tot een ontbrekende of verouderde versie van een bibliotheek of framework en een benodigd stuk code niet kan uitvoeren.
Wanneer macOS een van deze crashwaarschuwingen weergeeft, kunt u op de knop”Negeren”of op de knop”Rapporteren”klikken.
Als u op de knop”Rapporteren”klikt, geeft Finder een venster weer met het crashrapport en een knop”Verzenden naar Apple”. U moet het rapport naar Apple sturen als de fout door Apple-software is veroorzaakt.
Elk crashrapport wordt opgeslagen in een.ips-bestand in de map”DisagnosticReports”in uw gebruikersmap op/Users/~/Library/Logs/
U kunt ook deze rapporten in de Console-app van Apple door het item”Crashrapporten”aan de linkerkant van het consolevenster te selecteren, een rapport aan de rechterkant van het venster te selecteren en vervolgens Control-klikken of rechtsklikken op het rapport en selecteren”Onthullen in Finder”uit het pop-upmenu.
Dit opent de map DiagnosticReports in Finder en onthult alle opgeslagen crashrapportbestanden. Deze rapporten worden slechts een beperkte tijd door macOS bewaard en daarna begint het automatisch eerst met het verwijderen van de oudste rapporten.
Er is ook een menu-item”Verplaatsen naar prullenbak”in het console-pop-upmenu als u de geselecteerde crashrapportbestanden naar de prullenbak wilt verplaatsen.
Als u dubbelklikt op een.ips-bestand in Finder, wordt het alleen opnieuw geopend in de Console-app. Als u Control-klikt op een.ips-bestand in Finder en”Openen met”en vervolgens”Teksteditor”selecteert in het pop-upmenu, kunt u het.ips-bestand ook openen in Teksteditor.
Houd er rekening mee dat de tekst van elk rapport dat is opgeslagen in een.ips-bestand de indeling JSON heeft , dus je moet JSON kunnen lezen om het te begrijpen.
Crashrapporten lezen in Console
In ieder geval, als u een crashrapport selecteert in Console, kunt u de tekst ervan lezen in het hoofdtekstvenster hieronder it:
Laten we eens kijken naar de eerste paar velden in een crashrapport.”Proces”in UNIX betekent een actieve app. De velden zijn:
Proces-de naam van de app of het proces. Pad-waar het binaire bestand van de app zich op schijf bevindt. Identifier-meestal de binaire of bundelnaam, maar niet altijd. Versie-de binaire versie of ??? indien onbekend. Codetype-Intel of Apple Silicon.”Universeel”als beide. Bovenliggend proces-het binaire bestand of de app die dit proces heeft gestart. Gebruikers-ID-de UNIX-ID of PID van het proces-dezelfde proces-ID als weergegeven in Terminal.
Vervolgens hebben we de datum/tijd, de OS-versie, de rapportversie en een unieke UUID voor dit rapport. Er is ook een uniek slaap/waak-ID.
Het rapport vermeldt ook of System Integrity Protection is ingeschakeld of niet.
Vervolgens bevat het rapport details over de crash zelf. Deze informatie kan behoorlijk technisch zijn en is over het algemeen bedoeld voor programmeurs of voor Apple om te traceren waar het probleem zich voordeed in de applicatiecode, zodat het kan worden opgelost.
Meestal wordt het nummer van de thread die is gecrasht weergegeven-in dit geval de eerste thread-thread 0. Beschouw een thread als een codepad dat onafhankelijk van andere code wordt uitgevoerd. Op multi-core CPU-systemen kan elke kern een of meer threads hebben, waarbij alle kernen indien nodig parallel worden uitgevoerd. Dit staat bekend als parallel rekenen.
Vervolgens wordt het type crash of uitzondering vermeld:
Exception Type: EXC_CRASH (SIGABRT)
In dit geval SIGABRT-het UNIX-signaal om af te breken, of doden, de thread is verzonden. Signalen zijn berichten die UNIX naar actieve processen op een laag niveau stuurt om hen te vertellen iets te doen-in dit geval stoppen.
Meer informatie over UNIX-signalen en hoe ze werken is online beschikbaar.
Vervolgens zijn eventuele uitzonderingscodes, maar deze zijn vaak nul.
De”0x”voor elke code betekent dat de codewaarde in hexadecimaal of”hex”is in plaats van decimaal. Hexadecimaal is een getalsysteem met grondtal 16-met zestien waarden in plaats van tien zoals het decimale talstelsel heeft. Hex gebruikt 0-9 en vervolgens A-F als aanvullende waarden.
Je kunt lezen hoe het hex-nummersysteem werkt in elk goed boek over de C-programmeertaal.
Vervolgens is de beëindigingsreden, wat meestal een Engelstalige beschrijving is van de oorzaak van de crash. In dit geval”Namespace DYLD, Code 1 Library ontbreekt”.
DYLD is de Dynamic Loader-het deel van het besturingssysteem dat dynamisch code vanaf de schijf in het geheugen laadt wanneer deze moet worden uitgevoerd. U kunt meer lezen over DYLD in Terminal door man dyld te typen en op Return te drukken.
Naamruimten zijn naamgevingsconventies die in sommige programmeertalen worden gebruikt om delen van code te isoleren van andere code.”Code 1 Library missing”betekent dat DYLD heeft geprobeerd een dynamisch gekoppelde bibliotheek te laden, maar dat is niet gelukt.
Bij het programmeren zijn bibliotheken codebundels. Bibliotheken kunnen statisch zijn (gekoppeld aan een app tijdens het bouwen) of dynamisch (geladen in een app tijdens runtime).
Als de fout een DYLD-laadfout is, vertelt de volgende regel ons welke bibliotheek het was en waar het zich op schijf bevindt:
“Bibliotheek niet geladen: @rpath/VBoxRT. dylib”
In dit geval is VBoxRT.dylib een dynamische bibliotheek (.dylib) voor Oracle’s Virtual Box-toepassing. DYLD zocht naar de dynamische bibliotheek VBoxRT.dylib, maar kon deze niet vinden, dus de app kon niet worden uitgevoerd en kreeg het SIGABRT-signaal om te zeggen dat de app moest worden afgesloten.
Apps voor macOS en iOS bestaan in feite uit verschillende componenten-meestal een map met de naam Bundel
In dit voorbeeld zien we het binaire bestand van de app in de MacOS-map in de Inhoud map in de app-bundel:
Er is ook een map Bibliotheken en dan beide Apple Silicon-en Intel x86-bibliotheken in mappen in.dylib-indeling voor beide Mac-platformarchitecturen. Ze worden tijdens runtime geladen als dat nodig is door DYLD.
Sommige app-bundels kunnen vrij eenvoudig zijn, andere heel complex. Code en andere bronnen kunnen elders worden opgeslagen, buiten app-bundels.
In het bovenstaande voorbeeld wordt een.dylib extern opgeslagen en wordt normaal gesproken tijdens runtime geladen wanneer dat nodig is..dylibs zijn meestal enkele binaire bestanden in plaats van bundels.
Er is ook ondersteuning in iOS en macOS voor Frameworks, dit zijn bundels met code en andere bronnen. U kunt in de Finder binnen frameworks kijken op dezelfde manier als u in app-bundels kunt kijken met behulp van het hierboven genoemde pop-upmenu. Frameworks hebben altijd een versienummer in hun bundels.
Frameworks kunnen worden opgeslagen in app-bundels, of in/Library/Frameworks en/user/~/Library/Frameworks. Veel van macOS en iOS zelf zijn geïmplementeerd als dynamisch laadbare frameworks.
Apple heeft een Developer Framework-programmeerhandleiding die het laad-en bindproces voor macOS-en iOS-code in detail beschrijft. Het verbinden van twee stukken statisch gerelateerde code wordt koppeling genoemd in plaats van binding en wordt gedaan wanneer een toepassing wordt gebouwd met een compiler.
Statische code wordt allemaal tegelijk geladen, wat meer systeemgeheugen kan verbruiken.
Apple heeft ook een apart ontwikkelaarsdocument met details over de Objective-C-en Swift-runtimes, die beide aanvullende informatie bevatten over hoe code wordt geladen tijdens de uitvoering van de app.
Het laden van dynamische codes gaat helemaal terug tot eind jaren 70 met talen zoals SmallTalk. Op de platforms van Apple kwam het tot stand doordat Apple in 1997 NeXT kocht-en daarmee NeXT’s programmeertaal Objective-C verwierf, die pionierde in het gebruik van dynamische koppeling en introspectie.
NeXTStep Developer-een van de eerste ontwikkelaarspakketten gebruik dynamische binding.
Tegenwoordig wordt Apple-software nog steeds geschreven in Objective-C of Apple’s eigen Swift, die ook dynamische koppeling en laden gebruikt.
Dynamisch laden zorgt ervoor dat apps een kleinere geheugenvoetafdruk hebben, aangezien niet alle code en bronnen van een app in één keer in het geheugen hoeven te worden geladen. Het nadeel van dynamisch laden is dat het soms langzamer is, omdat bronnen van schijf moeten worden geladen terwijl een app actief is.
Dit is een van de meest voorkomende redenen voor de beruchte macOS-draaiende strandbalcursor.
Vervolgens in het crashrapport wordt ons verteld welk aanroepend proces of binaire code de overtredende code heeft aangeroepen, vermeld onder”Verwezen van:”. In dit geval was het het belangrijkste binaire bestand van de VirtualBox-toepassing dat was opgeslagen in de bundel van de app.
Het laatste stukje in het Engels leesbare informatie is”Reason:”, dat probeert een voor mensen leesbare reden te geven waarom de crash plaatsvond:
“‘/usr/lib/VBoxRT.dylib'(niet zo’n bestand, niet in dyld cache), (beveiligingsbeleid staat @ path-uitbreiding niet toe)
(beëindigd bij opstarten; negeer backtrace)”.
Dit betekent dat de bibliotheek die nodig was op/usr/lib/VBoxRT.dylib op schijf had moeten staan, maar dat niet was (het wordt daar meestal door het installatieprogramma van VirtualBox geplaatst), DYLD was niet eerder geladen het, en de app werd gedood bij de lancering.
Dus om samen te vatten, in het bovenstaande voorbeeld werd VirtualBox gelanceerd, maar een vereiste dynamische bibliotheek die niet kon worden gevonden, dus werd het gedood door macOS en stopte het. Alle informatie werd verzameld en toegevoegd aan het crashrapport.
Extra console-informatie en stacktraceringen
De rest van de informatie in het crashrapport is nog technischer, dus we zullen hier niet op elk detail ingaan , maar er zijn enkele dingen die u snel kunt lezen om te bepalen wat er is gebeurd.
U kunt met name de uitvoering van de code van de app volgen, in omgekeerde volgorde vermeld onder elk threadnummer, om te zoeken naar aanwijzingen waarom de crash plaatsvond. Niet alle crashes en gerelateerd aan ontbrekende bibliotheken, dus het is mogelijk dat de app correct is gestart, maar er was gewoon een programmeerfout in de code die een crash veroorzaakte.
Soms maakt een programmeur de fout systeemcode aan te roepen die niet bestaat, of zijn functieparameters heeft gewijzigd. Of het kan een geheugentoegangsfout zijn, of het overschrijven van variabelen in code met te veel gegevens die meestal iets aangrenzend in het geheugen overschrijven dat belangrijk was.
Al deze fouten kunnen een crash veroorzaken.
Deze informatie wordt normaal gesproken onmiddellijk na de sectie”Reden:”weergegeven en bevat meestal een lijst met genummerde functieaanroepen, met hun namen, adressen in het geheugen en hoe ze zijn geladen. Merk op dat u in deze sectie de lijst met functies (de stacktrace genoemd) wilt lezen, in omgekeerde volgorde-van onder naar boven.
Dit is de volgorde waarin de functies daadwerkelijk worden uitgevoerd.
In dit geval is de stapel erg kort en bestaat deze voornamelijk uit DYLD-voorbereidings-en stop/abort-signalen omdat de benodigde bibliotheek niet kon worden geladen bij het opstarten. Maar sommige fouten kunnen behoorlijk complexe stapels hebben.
Gewoonlijk is de laatste functie bovenaan (het einde) van de stapel degene die het probleem veroorzaakte-maar niet altijd.
Dit wetende kan handig zijn voor het diagnosticeren van crashes, aangezien de stack u de exacte functieaanroep kan vertellen die is mislukt. U kunt dan de naam van die functie opzoeken in de ontwikkelaarsdocumentatie van Apple om meer aanwijzingen te krijgen over wat er is gebeurd.
Soms wordt de naam van het framework of de bibliotheek die de crashfunctie bevat, vermeld in de stacktracering, wat nog meer informatie geeft.
Na het stackblok in het crashrapport staat informatie over de status van de thread, die niet echt relevant is tenzij je een ontwikkelaar bent, gevolgd door de CPU waarop de thread draaide, een eventuele foutcode, en een Trap-nummer. Traps zijn invoegpunten in OS-code die worden aangeroepen wanneer er een gebeurtenis plaatsvindt.
Crashgeheugen en samenvattingen
Vervolgens is er wat informatie over binaire bestanden (gecompileerde code) die betrokken zijn bij de crash-en dit zijn meestal, maar niet altijd de dezelfde info als vermeld bovenaan het crashrapport.
Daarna is er een External Modification Summary-samenvattingen van proces-ID’s die interactie hebben gehad met dit proces, en wat informatie over virtueel geheugen (VM) over welke delen van de code zich in het geheugen bevonden en welke nog op schijf stonden. Virtueel geheugen verwijst naar schijfruimte die het besturingssysteem gebruikt alsof het echte RAM is om het totale beschikbare geheugen dat door het systeem wordt gebruikt te vergroten.
Vervolgens is er informatie over het”regiotype”die aanvullende informatie samenvat over de stack, VM, link-en tekstsegmenten, en DYLD en gedeeld geheugen. U kunt deze informatie meestal negeren, tenzij u een ontwikkelaar bent.
Aan het einde van elk crashrapport is er een sectie”Volledig rapport”, wat in wezen een volledige onbewerkte JSON-dump is van het volledige.ips-bestand in tekstindeling. De onbewerkte JSON bevat wat aanvullende informatie die niet wordt weergegeven in het consolevenster, zoals Apple Mac-model-ID, CPU-type, code-ondertekening en andere informatie.
Houd er ook rekening mee dat een app meerdere threads kan hebben, dus voor elke thread wordt een soortgelijke samenvatting weergegeven als hierboven. Maar meestal staat het gecrashte threadnummer helemaal bovenaan het rapport, zodat u weet naar welk threadnummer u moet kijken.
Dit alles lijkt misschien overweldigend voor de nieuwkomer, maar als je het lezen van crashrapporten eenmaal onder de knie hebt, kun je meestal snel en gemakkelijk achterhalen wat er is gebeurd-en of je er iets aan kunt doen. Aangezien in het bovenstaande voorbeeld een vereiste bibliotheek ontbrak, zou een eenvoudige herinstallatie van de app met behulp van het installatieprogramma in orde zijn.
Apple biedt een gedetailleerde Console-gebruikershandleiding online, die is vrij informatief en nuttig.
