Accessing crash logs
The Mac stores various log files that contain all sorts of information sent by various system processes and apps. If you are just an average Mac user and not a developer, most of the information stored in these files – crash logs included – will look like gibberish. The reason is simple: these files are meant for developers and those that understand this sort of info to help them diagnose a problem. Many Mac users won’t even look at them, but, as you will see, they can be helpful for understanding and diagnosing problems.
You can access the crash log in macOS in two ways:
Deciphering crash logs
Now comes the hard part. At this point you will see a document with a lot of what looks like complete nonsense, but it is possible to pull salient information out from the report. Since the report has a number of different parts, it’s important to know which part contains the information that you can use to identify the problem.
The first part of the log contains information about the process that crashed. Sometimes the actual process that crashed isn’t the one you thought – think of the helper tools the apps contain – so the crash log helps you identify exactly which process it was that died.
After getting through the basic information such date and time or macOS version the next section you’ll want to get into is the type of crash or, in Apple’s terminology, “the exception”.
Apple defines four common forms of exception:
- EXC_BAD_ACCESS/KERN_INVALID_ADDRESS ?
This type is triggered by the thread accessing unmapped memory. It may be due to 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 most interesting part of the crash report is the backtrace information the crash log displays: it contains a backtrace for all the threads in the crashed process. This section describes, in reverse chronological order, the events that your Mac registered before the process died in each thread. A multi-threaded process includes multiple threads, a single thread, just one.
CrashReport makes things easier by tagging the faulty process in the backtrace with the text “Thread Crashed:”. Each line of the backtrace includes important information: the first column is the frame number, starting at item 0, which indicates the function that died; item 1, the function that completed immediately before the one that crashed; item 2 the function occurring before item 1, and so on.
The second column is the name of the process or other system components performing the task. In our example, this was “libsystem_kernel.dylib”, as you can see in the image above. The third column contains the counter program address, while the fourth displays the symbolic name for the program counter address given in the third column.
Fortunately, you don’t have to deal with this information if you are an average Mac user. But, as you can see, crash logs are useful for identifying and solving the issue that caused the app to quit unexpectedly if you know where to look.
Now you know what to copy and paste when sharing crash logs on blogs and forums in order to get help.
István F.
Adam B.
