Crash (computing)
|
|
A crash in computing is a condition where a program (either an application or part of the operating system) stops performing its expected function and also stops responding to other parts of the system. Often the offending program may simply appear to freeze. If this program is a critical part of the operating system kernel the entire computer may crash (a system crash).
Many crashes are the result of the execution of a single machine instruction, but the causes of this are manifold. Typical causes are when the program counter loses track of the correct execution path or a buffer overflow overwrites a portion of program code, due to an earlier bug. In either case it is quite common for the processor to attempt to execute data or random memory values. Since all data are possible, but only some of these are valid instructions, this very often results in an illegal instruction exception. One might say that the original bug that upset the program counter "caused" the crash, but the actual fault was an illegal instruction, possibly some time later. The art of debugging such crashes is connecting the actual cause of the crash (easily determined) with the code that set off the chain of events. This is often very far from obvious - the original bug may in fact be perfectly valid code from the processor's perspective.
On earlier personal computers, it was acutally possible to cause hardware damage through trying to write to hardware addresses outside of the system's main memory. Occasionally, excecution of arbitrary data on a system will result in a breakup of screen display. This is widely considered to be a severe system crash.
Another cause of crashes is a race condition in communication between processes. One process may send a signal to a second process then stop execution until it receives a response. If the second process is busy the signal will have to wait until the process can get to it. What if the second process was busy sending a signal to the first process and also stops execution until it receives a response? In this case, both processes wait forever for the other to respond to its signal and never see the other’s signal. If the processes are uninterruptable they will hang and have to be shut down. If at least one of the processes is a critical kernel process the whole system may crash and have to be restarted.
| Contents |
Application crashes
An application typically crashes when it performs an operation which is not allowed by the operating system. The operating system then shuts down the application.
Typical errors that result in application crashes include:
- attempting to read or write memory that is not allocated for reading or writing by that application (general protection fault)
- attempting to execute privileged or invalid instructions
- attempting to perform I/O operations on hardware devices to which it does not have permission to access
- passing invalid arguments to system calls
- attempting to access other system resources to which the application does not have permission to access (bus error)
Operating system crashes
An operating system crash often happens when a hardware exception occurs which cannot be handled, such as a hardware exception occurring within the operating system itself.
Operating system crashes can also occur when internal sanity-checking logic within the operating system detects that the operating system has lost its internal self-consistency.
In an ideal world, well-written operating systems should not be able to be crashed by application-level activity. However, until 1993, with the release of Windows NT 3.1, this hasn't been the case for the average PC. Industrial strength systems have enjoyed this sort of stability for much longer.
See also
- freeze (computing)
- black screen of death
- blue screen of death
- Safe Mode
- debugging
- kernel panic
- reboot
- recovery
External links
- Microrecovery & Microreboot / Crash-Only Software (http://crash.stanford.edu/)
- Citations from CiteSeer (http://citeseer.ist.psu.edu/cis?q=Crash)it:crash (informatica)