What conditions cause panics?


While some folks see panics as horrible things, they really should be seen as system and data integrity safeguards. A good operating system programmer will embed calls to the panic() routine throughout his code when checking the integrity of the system resources he is referencing and manipulating.

For example, if the system programmer's section of code is about to free up a block of disk that is known to be in use, he might have his program first verify that the disk is still marked as in use. If the block is suddenly found to be marked as free before he freed it, then his code should not be freeing it. But how did the block magically become free? Somehow, somewhere, something went terribly wrong. By calling panic(), the system programmer can bring the system to a sudden stop, thus safeguarding the system and its data from additional corruption until the problem is found.

panic() can only be called by the operating system while in kernel mode. No user, not even the super- user , whom we will often refer to simply as "root" throughout this book, can actually write an application program that calls panic() . However, any program that exercises a bug in the operating system might trigger a panic. For example, if the user's program uses a new device driver that is still being debugged , program execution moves into kernel mode whenever the driver is needed. Once in kernel mode, panics are possible. It may appear to the user that his program panic'ed the system, but in reality, his program only triggered the chain of events that led to the panic.

Simply put, if a system panics, it is really because the operating system detected a condition where the integrity of the data was suspect or the data was in danger of being corrupted.

Let's try this data integrity concept again from a user level programming point of view. If you write a program that opens a file by using the open () system call, you will presumably check the return status of open() to make sure the desired file was indeed opened successfully before going on to the next step. If the open() status shows that an open failure occurred, you will probably have your program report this condition and either exit, prompt the end user for a new filename, or simply take a different course of action. If you open the file and ignore the status returned from the open() system call, you are asking for potential problems further down the line. The integrity of your data is at risk.

Does the automobile that you drive have something similar to the panic() routine? If it is equipped with air bags, then the answer is yes. When your car senses that something is very wrong, such as the front bumper suddenly being involved in a high-speed collision, chances are good that the air bag will inflate, thus (hopefully) preserving its driver.

As another example, this time from a chef's point of view, how many times does he want to add one pinch of salt to the dish he is preparing? If a chef could use panic(), he might use it to prevent someone from adding a second, third, or hundredth pinch of salt that would most certainly ruin the dish. The integrity of his epicurean masterpiece would be protected.

Given a choice, it is better to have more data integrity checks throughout the system code rather than less. Your data is safer in an operating environment that has built in safeguards throughout the code.

Note

Technically speaking, a Solaris 2 system programmer may call panic() or he may choose to call the cmn_err() routine giving a severity error condition code of CE_PANIC . Cmn_err() acts as a common, multipurpose, error-handling routine, whereas panic() is designed specifically for panic scenarios. In Sun's Solaris 2, both cmn_err(), when called with a code of CE_PANIC, and panic() call do_panic() , which in turn calls setup_panic() and finally, complete_panic() . From this point on, for purposes of simplicity, when we refer to panic() we also are talking about cmn_err() and other vendors ' routines that help to eventually panic the system.




PANIC. UNIX System Crash Dump Analysis Handbook
PANIC! UNIX System Crash Dump Analysis Handbook (Bk/CD-ROM)
ISBN: 0131493868
EAN: 2147483647
Year: 1994
Pages: 289
Authors: Chris Drake

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net