Known Users


Known Users

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


Return to:
Known Users archive