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.
The main details of a crash report outline information in separate sections about the process, and outline essentially what the system last saw about the program before it was terminated. This includes any open files (executable and otherwise) that the program had open, application-specific information, and execution threads in which the program was running.
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.
