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

UptoLike

ВУЗ: 

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

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

Рубрика: 

96
disk?» However, if the OS's error-handling code is deficient, more dominoes fall, and
eventually the whole system crashes.
Sometimes a program gets stuck in an infinite loop. Due to an unexpected
condition, the program repeatedly executes the same block of code over and over
again. (Imagine a person so stupid that he or she follows literally the instructions on a
shampoo bottle: «Lather. Rinse. Repeat.») To the user, a program stuck in an infinite
loop appears to freeze or lock up. Actually, the program is running furiously.
Again, a good OS will intervene by allowing the user to safely stop the process.
But the process schedulers in some OSes have trouble coping with this problem. In
Windows 3.1 and the Mac OS, the schedulers work cooperatively, which means they
depend on processes to cooperate with each other by not hogging all the CPU time.
Windows 95 and NT, OS/2, Unix, Linux, and most other modern OSes allow a
process to preempt another process.
Race conditions are similar to infinite loops, except they're usually caused by
something external to the program. Maybe the program is talking to an external
device that isn't responding as quickly as the program expects – or the program isn't
responsive to the device. Either way, there's a failure to communicate. The software
on each end is supposed to have time-out code to handle this condition, but
sometimes the code isn't there or doesn't work properly.
Resource starvation is another way to crash. Usually, the scarce resource is
memory. A program asks the OS for some free memory; if the OS can't find enough
memory at that moment, it denies the request. Again, the program should anticipate
this condition instead of going off and sulking, but sometimes it doesn't. If the
program can't function without the expected resources, it may stop dead in its tracks
without explaining why. To the user, the program appears to be frozen.
Even worse, the program may assume it got the memory it asked for. This
typically leads to a memory violation. When a program tries to use memory it doesn't
legitimately own, it either corrupts a piece of its own memory or attempts to access
memory outside its partition. What happens next largely depends on the strength of
the OS's memory protection. A vigilant OS won't let a program misuse memory.
When the program tries to access an illegal memory address, the CPU throws an
exception. The OS catches the exception, notifies the user with an error message
(«This program has attempted an illegal operation: invalid page fault»), and attempts
to recover. If it can't, it either shuts down the program or lets the user put the program
out of its misery.
Not every OS is so protective. When the OS doesn't block an illegal memory
access, the errant program overwrites memory that it's using for something else, or it
steals memory from another program. The resulting memory corruption usually
sparks another round of exceptions that eventually leads to a crash.
Corruption also occurs when a program miscalculates how much memory it
already has. For instance, a program might try to store some data in the nonexistent
101st element of a 100-element array. When the program overruns the array bounds,
it overwrites another data structure. The next time the program reads the corrupted
data structure, the CPU throws an exception. Wham! Another crash.

Страницы