Computer World. Матросова Т.А. - 96 стр.

UptoLike

ВУЗ: 

УлГТУ | Ульяновск

Составители: 

Рубрика: 

95
Causes Behind Crashes
You can sort the technical reasons for crashes into two broad categories:
hardware problems and software problems. Genuine hardware problems are much
less common, but you can't ignore the possibility. One downside to the recent sharp
drop in system prices is that manufacturers are cutting corners more closely than ever
before. Inexpensive PCs aren't necessarily shoddy PCs, but sometimes they are.
Generally, though, when a computer crashes, it's the software that's failed. If it's
an application, you stand to lose your unsaved work in that program, but a good OS
should protect the memory partitions that other programs occupy. Sometimes,
however, the crashed program triggers a cascade of software failures that brings
down the entire system.
So why do programs crash? Chiefly, there are two reasons: A condition arises
that the program's designer didn't anticipate, so the program doesn't handle the
condition; or the program anticipates the condition but then fails to handle it in an
adequate manner.
In a perfect world, every program would handle every possible condition, or at
least it would defer to another program that can handle it, such as the OS. But in the
real world, programmers don't anticipate everything. Sometimes they deliberately
ignore conditions that are less likely to happen – perhaps in trade for smaller code,
faster code, or meeting a deadline. In those cases, the OS is the court of last resort,
the arbiter of disturbances that other programs can't resolve. «At the OS level, you've
got to anticipate the unanticipated, as silly as that sounds,» says Guru Rao, chief
engineer for IBM's System/390 mainframes.
To deal with these dangers, programmers must wrap all critical operations in
code that traps an error within a special subroutine. The subroutine tries to determine
what caused the error and what should be done about it. Sometimes the program can
quietly recover without the user's knowing that anything happened. In other cases, the
program must display an error message asking the user what to do. If the error-
handling code fails, or is missing altogether, the program crashes.
Autopsy of a Crash
Crash is a vague term used to describe a number of misfortunes. Typically, a
program that crashes is surprised by an exception, caught in an infinite loop, confused
by a race condition, starved for resources, or corrupted by a memory violation.
Exceptions are run-time errors or interrupts, that force a CPU to suspend normal
program execution. (Java is a special case: The Java virtual machine [VM] checks for
some run-time errors in software and can throw an exception without involving the
hardware CPU.) For example, if a program tries to open a nonexistent data file, the
CPU returns an exception that means «File not found.» If the program's error-
trapping code is poor or absent, the program gets confused. That's when a good OS
should intervene. It probably can't correct the problem behind the scenes, but it can at
least display an error message: «File not found: Are you sure you inserted the right

Страницы