First up, the term exception is heavily overloaded. Please read What is an exception? before continuing.
The page you referenced is pretty good. For example, it mentions EXC_BAD_ACCESS, the exception you’re seeing, and points you to Investigating Memory Access Crashes, which is the process you should be following.
Do I really need to know what each code as given in the error message
represent?
You mean the codes within a given exception? In most cases you don’t care about those; rather, it’s the exception type that actually matters. That certainly true for EXC_BAD_ACCESS.
As to what those codes mean, you are correct that there is no comprehensive documentation about that. The documentation we do have, like Understanding the Exception Types in a Crash Report, only talks about these codes when they are likely to be useful.
If you really want to know, I recommend that you look at the comments next to the exception type declaration in <mach/exception_types.h>. For example, for EXC_BAD_ACCESS it says:
/* Code contains kern_return_t describing error. */
/* Subcode contains bad memory address. */
In your example:
If the comments in <mach/exception_types.h> are insufficient then the next step is to dig into the kernel source code in Darwin. I think it’s safe to say that this is overkill for your issue (-:
I think I found documentation at one time for those codes at another
source outside of Apple.
That’s possible — there’s plenty of third-party documentation for Apple stuff — but it’s not very relevant. These codes are set up by Apple code running within the kernel. In most cases the codes are hardware independent. In some cases the codes may map to a hardware-specific value, but it was Apple’s decision to use a direct mapping and we could have just as easily remapped them.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
