Error Codes: A hunt for clarity



Author: Apple Technical Communications

Date: April, 1989

Keywords: errors troubleshooting tips system hints

Text:
(Editor's note: I ran across this on one of my disks. It may be helpful
-- I'm not sure. It could raise more questions than it answers*)
No document can detail the various Macintosh system errors because
system error codes themselves are not very descriptive. The Macintosh
provides almost no internal error reporting mechanism and the
architecture's complexity usually renders the error codes meaningless.
 Here's a metaphor. Suppose you're driving down a road and you see a
car rammed head-on into an oak tree, all in flames. 
What happened? Was the driver drunk? The road slippery? Did a tire
blow? 
All physical evidence is destroyed because of the impact; if you
weren't there to see the accident, up close, there's no way for you to
know exactly what happened. If you could re-live it, in slow motion,
maybe you could see the causes (obvious or subtle), and if you were an
auto mechanic, road builder or doctor, perhaps you could prevent it
from happening next time.
 So it is with Macintosh. A million things can go wrong in very complex
ways: a handle can be dereferenced, or a routine can get a NIL pointer,
or the stack can dip into the heap for just a few cycles and not be
caught by the stack sniffer, or an application can forget to check an
error code.
 Whatever the cause, the result is that the Macintosh loses control and
hits the oak tree.
You don't know which oak tree it will hit on which road; sometimes it
can careen for seconds on end before executing an unimplemented
instruction or jumping through an invalid return address.
 A user can do almost nothing for an application that shows a system
error ID on a crash. If it's reproducable, the programmers are usually
very interested in seeing how it was done; but finding out what's wrong
involves use of debugging tools, intricate knowledge of Macintosh
memory structures and familiarity with the application itself. Fixing
it usually involves recompiling the source code.
 But whatever happens, if Macintosh ever gets out of control, it will
usually crash with a system error code. For your information, here's
what can be said about the codes:
 ID=02 is Address Error; that means a word- or longword-based
instruction was passed to an odd address. Since that's a 50/50
proposition when running random code, this one shows up quite often.
 
ID=03 is Illegal Instruction; less likely than 02, but still very
common.
 
ID=07 (Privilege Violation), 06 (TrapV Exception), 11 
(Miscellaneous Exception), and 12 (Unimplemented Core Routine) almost
always happen because of getting loose, and those probably cover 90
percent of the crashes.
 ID=04 is a Divide By Zero; either a programmer was dumb and didn't
check or the program got loose, or in some cases the programmer puts
these in as debugging aids and forgets to take 'em out. Same for ID=10
(Line 1111) and ID=05 (Check Exception). ID=08 (Trace Exception), 13
(Spurious Interrupt), and14 (I/O System Error) are hardware-related and
should not be seen on a Macintosh except when strange hardware or
debugging tools are in.
 ID=15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 26, 27, 30 and 31 all come
up when the System file is trashed. Replacing the System file may cure
these.
 The only ones left are ID=25, 28, and 31. All of these are memory
errors: memory full, stack overflow or memory manager failed. You'll
see these when running a 512K application on a 128K machine, or under
Switcher in too-small partitions.
Apple Technical Communications

Copyright © april, 1989 by Apple Technical Communications