Exceptions

Depends on	Concepts

In general, in computing terms, “exceptions” are circumstances which are outside the normal operations flow. For example, when accessing an array an exception could be caused if the index referred to an element beyond the size of that array.

You may already be familiar with some classes of exceptions, e.g. from Java.

The operating system software layer is also capable of generating exceptions. You are probably already familiar with the ^C method of terminating an application; note that there will usually not be an explicit check for this input in the application’s code. There is a further exploration of this principle in the exercise on exceptions.

Here we are primarily concerned with exceptions which originate from hardware which are normally handled by the operating system. The sort of exceptions supported by particular hardware varies but here are some examples of exceptions at the hardware level.

• Reset – used to start a system in a well defined way
• System call
• Emulator trap
• Memory fault
• Interrupt
• Privilege violation
• Arithmetic error (e.g. division by zero, numeric overflow)
• Debug breakpoint
• …

Here is a (somewhat cryptic) list of x86 processor exceptions.

It is likely that all of the exceptions supported by a particular machine call into the operating system. For space reasons we only describe a selected, illustrative subset here; see the individual articles for more details.

Common features

The typical hardware exception is a high-priority event which is likely to take precedence over other tasks. Some are a result of a software action (e.g. a system call); some originate purely from hardware (e.g. an interrupt); some come from an interaction between hardware and software (e.g. a page fault). All have a certain commonality in response.

An exception acts as a ‘call’ to the processor, invoking a method/procedure/subroutine/whatever-you-call-it. The process of the call also raises the privilege level of the processor so that it can legitimately interact with the hardware. This routine is entered at a well-defined address which is normally reserved for operating systems’ code and should have appropriate protection which stops user processes abusing the facility.

Now running trusted code, the processor can determine more information about the cause of the exception. It takes appropriate remedial action. Depending on the particular circumstances it may be able to deal with the exception transparently, and return to the user code transparently, or it may decide that the issue cannot be ‘fixed’ and not return, instead, perhaps, scheduling some other action.

The detailed behaviour may need to be a software (O.S.) decision. For example:

• A memory fault caused by a ‘rogue’ pointer probably indicates a process has crashed (or is trying to do something illicit) and the guilty process will be exterminated.
  (E.g. “Segmentation fault”).
• A memory fault caused by a virtual memory page fault will normally cause some corrective action and the user process will be resumed sometime later.
  (Other processes may be scheduled in between.)
• A memory fault used to track whether a page is still in use will simply note the status and return ‘immediately’.
  (Some systems do do this – but don’t worry if you don’t follow this last point.)

The exception handler might also send a signal to communicate information back to a user process. A user process can sometimes register its own signal handlers for some exceptions.

There is an exercise for you to try this.

---

Exact and Inexact Exceptions

Hardware exceptions may be broadly classed as being ‘exact’ or ‘inexact’, depending on the relationship of the cause to the place the software responds to them.

• Exact exceptions occur at a fixed position. The most obvious example is the system call which is an explicit instruction at a fixed place in the code. A less obvious example is the memory fault; however in a system using virtual memory it is important that the exception handler can identify exactly where the ‘fault’ occurred (e.g. within a sequence of load operations) so that it can identify the correct page … and return to rerun the operation.
• Inexact exceptions are typified by interrupts and there is no way to predict when they might be serviced. The implication for operating system code is never to allow interrupts in an atomic sequence of instructions to prevent context switching etc. within the sequence.

---

Also refer to:	Operating System Concepts, 10th Edition: Chapter 12.2.3, pages 494-498

Context Dependencies Dependants

Max. number:

Max. distance:

Next

Articles on Concepts

About this resource • Application Binary Interface (ABI) • Arrays • Atomicity • Boot • Cache • Cacheability • Caching • Concepts • Containers • Context • Context Switching • Deadlock • Direct Memory Access (DMA) • Environment Variables • Exceptions • File Attributes • Fragmentation • Hypervisor • Interrupts • Operation Ordering • PATH • Pointers • Process Scheduling • Processes • Processor Privilege • Queues • Real Time • Reentrancy • Relocatable Code • Spooling and Buffering • Synchronisation • Thrashing • Threads • Virtual Memory • Virtualisation

Articles on Exceptions

Boot • Emulator traps • Errors • Exceptions • Interrupt Controller • Interrupt Service Routines (ISRs) • Interrupts • Memory Fault • Reset • Software Exceptions • System Calls

Articles on Major concepts

Cache • Cacheability • Concepts • Context • Direct Memory Access (DMA) • Exceptions • Hypervisor • Metadata • Process Scheduling • Processor Privilege • Real Time • Reentrancy • Synchronisation • Virtualisation

Articles on User

"Everything is a File" • Application Binary Interface (ABI) • Arrays • Boot • Buffer Overflow • Containers • Daemons • Disk Partition • Dynamic Memory Allocation • Emulator traps • Environment Variables • Errors • Exceptions • File Attributes • File Locking • File Permissions • Introduction to Operating Systems • Journalling File System • Links • Locks • Man(ual pages in Unix) • Memory Mapped Files • Monitoring • Network File System (NFS) • PATH • Pipes • Pointers • Relocatable Code • Reset • SETUID • Shell • Sockets • Spooling and Buffering • Streams • Structures • Superuser • System Calls • Unix Signals • User • Using Peripherals