Whenever a program crashes in OS X, you are presented with a small window that indicates the program quit unexpectedly (Apple’s vernacular for “it crashed”). Whenever this happens, first choose the default option in this window to ignore the issue, and then try relaunching your program. However, if it occurs again then you may find some quick answers in the crash report that can be opened by clicking the “Report” button.
When you open this report, you will see a bunch of cryptic-looking details that may seem only useful to a programmer, but with careful review you may spot something that can help you overcome your problem.
For the most part all of the details of a crash report can be ignored, but if you look at each of the subsections in whole you are presented with a view of what the system saw when the program crashed. In most cases, you will see a specified point where the program crashed, indicated by a “Thread crashed” or similar content.
The crash reporter alert will show whenever a program has unexpectedly quit.
Unfortunately there is no stereotyped approach to reviewing a crash report that will get you an answer at all times, but by reviewing a case or two you may pick up some approaches that can help you troubleshoot your situation.
In the example here, Apple’s Photos program was crashing every time it was opened. This behavior is common when a configuration for a program is corrupt, or if a corrupted file previously opened by the program is being re-opened on launch.
In looking at the crash report, we can see that “Thread 3” is the process that crashed:
The crash report shows cryptic details about the crashed thread, but you can see some more relevant actions that were taken, listed toward the top (click for larger view).
If you do not know what threads are, programs for your computer are broken down into separate running parts called threads, which in part allow the program to run more modularly and not get hung up on any particular task. For instance, without threading, the act of opening a file would freeze any running program while it waits for user input, but having this file-opening task be in a separate thread means the main program can keep running and wait for the file to be chosen and presented, so nothing has to pause.
Programs can be more stable in this manner as well, since threads experiencing problems can often be restarted instead of taking down the whole program. This being said, often for logical and nuanced programming reasons, back-end features that are core to a program’s functions will run in separate threads, but if any one runs into problems, then they will cause the program to fail.
In looking at the report, it is obvious nothing much can be gleaned from the details about this thread, since it simply references library names and system calls. We simply know that an abort command was called and that the thread has to do with OpenGL (a graphics library). This lets us know the thread had to do with rendering graphical content from Photos.
While the thread report does not show much, scrolling up does show a key to the puzzle. Under the listing of process details we can see Application Specific Information, where an “Assertion failure” entry is listed. An assertion failure to a programmer means some program state that was expected has not occurred, and therefore the program is being forced to quit instead of proceed in a potentially unsafe state. This is good, and indicates the program is in fact behaving according to its coding, despite crashing.
The application-specific details about the crash show a specific cached file that is suspect, indicating the solution here is to clear this cache and allow the program to recreate it (click for larger view).
As with reading thread details, the specifics of an assertion failure may be difficult to diagnose, but in this case we can see an implicated cache file. Caches are just small settings and states that are stored from the last time the program ran, which may be quickly accessed for the program to run more efficiently the next time it loads. This is also good, because it means they are temporary files that are dynamically recreated.
In this case, a misconfiguration of this indicated cache file is all that was the problem, and going to its specific location on disk (Macintosh HD > Library > Caches > com.apple.xbs > Sources > PhotoApp > PhotoApp-370.42 > lib > paimaging > PhotoApps) allows us to remove the cached file so Photos can open again. You can also take a more global approach and delete the parent “com.apple.xbs” file in the Caches folder itself, which will force Photos to recreate all of its cached files.
Off-topic a bit:
I’m intrigued: what is a .m file doing in Photos’ cache? In Xcode’s cache, I could understand.
Running Photos on 10.11.3 didn’t produce any com.apple.xbs/ for me, though it may have come and gone quickly.
I can’t even find this .m file on my 10.11.3 iMac, neither with Spotlight (with search system files allowed) or with Find Any File, and I do have Xcode installed with Mac and iOS SDKs.
Weird. Maybe the user dropped it into the cache folder somehow, forcing Photos to look at it, though even that’s strange.
This report appears to be unique on Google, except for a Vietnamese report that I can’t read and appears to be irrelevant in any case.
Thank you so much for this. I have looked online for years for a breakdown of the mac error report that is written for the ordinary reader. Well done.
Where I have found crash reports particularly helpful is when cloning a hard drive fails. This has happened more often with SuperDuper! than with Carbon Copy Cloner, but that may be situational and not app related. In any case, when I check the fail point for a clone in the app’s log file, what I usually find is a corrupt file that can easily be deleted so that the clone can continue. In the worst case there were several of these and though it may be a clumsy way to find bad files, still it’s a solution that works.
As in Topher’s example, bad data is most often the cause of a crash. The trick is running down that data. Likewise bad data most often occurs in cache files. One way to avoid this problem is to use a utility that deletes cache files. If you often use your computer at 2:00 in the morning, the system’s Cron scripts will do the job. Otherwise, a third party utility like Maintenance (free) or Cocktail will do if you run them periodically. In particular, I run the (auto)Pilot routine in Cocktail before updating the clone of my boot drive so, to the extent possible, I am not saving the chuff that accumulates as you use your computer. FYI, Maintenance and Cocktail address a wider range of cache files than the Cron scripts alone will do.
Obviously there’s no way of knowing how much trouble you have avoided by doing routine maintenance on your drive(s), but when I troubleshoot client’s computers, it’s usually the case that they do not do any maintenance, routine or otherwise. By the time they call me, therefore, they are in crisis. I’ve given up trying to get people to do routine maintenance themselves because either they are intimidated by the very idea of fixing their own computers, or they don’t take the issue seriously—until it’s too late, and sometimes not even then. As the saying goes, you can lead a horse to water but you can’t make him drink.
Thanks again, Topher, for digging into the dark corners and shinning a light there for us.