Tutorial: An introduction to reading Mac OS X crash reports
Tutorial: An introduction to reading Mac OS X crash reports
The advent of the CrashReporter in Mac OS X was a boon for developers -- suddenly, a capsule of what caused the problem with a given application could be instantly captured by the end user and sent back to the developer for examination.
Unfortunately, deciphering the logs generated by CrashReporter (stored in ~/Library/Logs/CrashReporter) can be a daunting task, making them less than explanatory for a user attempting to diagnose problems on their own systems.
The following is a quick introduction to pulling salient information from crash reports and using them in potential troubleshooting routines.
Operating System, date and time The first section of a crash report looks something like this:
Date/Time: 2006-03-09 01:15:10.431 -0500OS Version: 10.4.5 (Build 8H14)
Report Version: 4
Since you should already be aware of your current Mac OS X version and the date, this section is not of much concern to the end user, and is more useful for developers looking for patterns implicating a specific iteration of Mac OS X.
What process crashed The next section of a crash report should look like this:
Command: iMovie HDPath: /Applications/iMovie HD.app/Contents/MacOS/iMovie HD
Parent: WindowServer [63]
Version: 6.0.1 (6.0.1)
Build Version: 2
Project Name: iMovieApp
Source Version: 2550000
This section will tell you the name of the process that crashed. In this case, said process is the application iMovie.
Looking at this section is particularly useful if you're not sure which application caused a crash. It is also worth looking at if you think you know which application crashed, but aren't sure. Many applications make use of Apple-spawned processes or other components of which the user may not be aware.
The exception (type of crash) The next section looks like this:
Exception: EXC_BAD_ACCESS (0x0001)Codes: KERN_INVALID_ADDRESS (0x0001) at 0x1718b000
and tells the user exactly what type of processor exception caused the crash.
According to Apple, there are four common types of exception:
- EXC_BAD_ACCESS/KERN_INVALID_ADDRESS ? This is caused by the thread accessing unmapped memory. It may be triggered by either a data access or an instruction fetch
- EXC_BAD_ACCESS/KERN_PROTECTION_FAILURE ? This is caused by the thread trying to write to read-only memory. This is always caused by a data access.
- EXC_BAD_INSTRUCTION ? This is caused by the thread executing an illegal instruction.
- EXC_ARITHMETIC/EXC_I386_DIV ? This is caused by the thread doing an integer divide by zero on an Intel-based computer.
The backtrace The next section looks something like this:
Thread 0 Crashed: 0 main 0x16bf2c34 DoFastCopyMap__FPUclPUcl4Rect1 main 0x16bf2d90 FastCopyGworldsCPP 240
2 main 0x16bf2bd0 FastCopyGworlds 32
3 main 0x16bf066c DoPascalLineArt 356
4 main 0x16befcac DoEffect 124
This section shows, in reverse chronological order, the series of events that happened right before the crash in each thread. Fortunately, Mac OS X tells you which thread crashed. In the above example, Thread 0 crashed.
The first column indicates order (again, reverse chronological). 0 is the task that was taking place when the exception (crash) occurred, item 1 the task right before that, item 2 the task that occurred before item 1, etc.
The second column indicates the name of the program or other system component that performed the task. In the above case, "main" is actually an iMovie plug-in. However, you might also see something like "com.apple.iMovie" here -- which would point to the application iMovie itself.
The third column is the counter program address (e.g. 0x16bf2c34) -- don't worry about this for now -- and the fourth column displays the task (e.g. DoFastCopyMap__FPUclPUcl4Rect) that is taking place.
Now we know that the process "main" is responsible for the exception (crash). Specifically, the DoFastCopyMap__FPUclPUcl4Rect task. But before that task, the following occurred:
DoEffect > DoPascalLineArt > FastCopyGworlds > FastCopyGworldsCPP > DoFastCopyMap__FPUclPUcl4Rect
Thankfully, the developer of the aforementioned plug-in (CF/X) was nice enough to include procedure labels that indicate each task. Most applications (including most of Apple's), however, do not do this, and you will instead see a numerical representation of a task.
With this information, you should be able to tell what application (or plug-in) caused the system crash, and what series of events triggered the crash. You can then take appropriate action -- attempting to revert to an earlier version of said application, avoiding use of a plug-in (or deleting it), or running general maintenance procedures and checking for persistence of the issue.
Feedback? Late-breakers@macfixit.com.
Like what you've found in this tutorial? Get more troubleshooting guidance (updated daily) by subscribing to MacFixIt Pro.
Resources