Yesterday I spent some time looking at OS X crash logs; as anyone who has been working on the OS X platform as long as I have will have noticed, the precise format of the crash logs your applications generate is now somewhat different to the reports that were generated way back on OS X 10.0.
Indeed, Apple documents no fewer than six versions of the crash log format, and that doesn’t include the variants in use on iOS, the effects of running applications under Rosetta, or a couple of newer formats that have appeared more recently. Aside from version 1 crash logs, all of the formats include a field named “Report Version”; a more complete table of crash log versions would look like this:
|1||Mac OS X prior to 10.3.2|
|2||Mac OS X 10.3.2 through 10.3.9|
|3||Mac OS X 10.4.x on PowerPC|
|4||Mac OS X 10.4.x on Intel|
|5||Apparently never shipped|
|6||Mac OS X 10.5 through 10.7|
|10||Mac OS X 10.8 and later|
|11||Mac OS X 10.8 spin/hang report|
|101||iOS 1 (reported as OS X 1.x)|
|104||iOS 3 and later|
symbolicatecrash script that is used with iOS crash
reports doesn’t appear to know about report version 101, but does know about
report version 102. In case you don’t already know,
symbolicatecrash can be
(With Xcode 4, this is inside the application bundle, so tack
/Applications/Xcode.app/Contents onto the front too).
There’s little point going through all the changes between the different versions on Mac OS X, because, up to version 6 at least, they’re more than adequately documented in TN2123. Its iOS counterpart, TN2151, seems rather less useful, though it does at least include a list of exception codes that you might see.
iOS does differ a bit, though; it doesn’t include the “Command” field from Mac OS X, but it does include fields named “Incident Identifier” and “CrashReporter Key”, the former of which is a UUID and the latter of which is a 40 character long hexadecimal number.
Additionally, if a thread has been assigned a name using
pthread_setname_np(), on Mac OS X the backtrace for that thread will start
with a line resembling the following:
Thread <number>[ Crashed]:: <name of thread>
while on iOS you’ll see two lines:
Thread <number> name: <name of thread> Thread <number>[ Crashed]:
Obviously the thread state dump (with the registers) will differ from processor to processor, but there are additional differences in the format of the “Binary Images” section.
One other interesting feature (and it was this that got me interested yesterday) is that some crash reports now contain additional information labelled “Application Specific Information” or similar. This could be quite useful, but the mechanism by which it appears is completely undocumented…
Anyway, as a result of my investigations yesterday, it seems there are two
different mechanisms for adding this to a crash report. On Mac OS X and iOS,
there is a special symbol
__crashreporter_info__ that you can define that
lets you add to the “Application Specific Information” field; e.g.
1 2 3 4 5 6 7 8
asm statement is used to mark the
__crashreporter_info__ field as
“referenced dynamically”; this means it won’t get stripped and will be
included in the resulting binary so the crash reporter can see it.
I don’t know exactly which version of Mac OS X this was added in, but it is the older of the two mechanisms and exists on iOS as well.
On newer versions of Mac OS X, you can also give extra information to the crash reporter via a special data structure:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
Both of these mechanisms are per image. That is, the crash reporter will
collect up information from every image loaded into the address space of the
crashed process. In the case of the “Application Specific Information” field,
the messages are output one after the other; the same is true for the
“Application Specific Signature” field. If you are generating your own
backtrace (as the
NSException code does), each backtrace is output
separately, and they are numbered… for instance, if we change the line
then the resulting crash log will contain two backtraces labelled “Application Specific Backtrace 1” and “Application Specific Backtrace 2”.
None of this is documented. If you are going to use it, be sure that you
initialise the variables to zero/NULL, and DO NOT USE THE