Operating System Trap: What causes addressing errors to occur?

Question

After allocating a logical memory space for a particular process, protection to that space is enforced by using a base register and limit register. To defend against accessing memory outside of the allocated memory space for a process, CPU hardware compares each requested memory address to these registers. If one of the two following conditions holds, an operating system trap occurs:

1. The target address is less than the base register.
2. The target address is greater than or equal to the limit register.

This logic can be visually observed in Figure 7.2 below.

The above explains how they occur, e.g.

any attempt of a program executing in user mode to access operating-system memory or other user’s memory results in a trap to the operating system.

But what are some examples of when the requested address would actually be outside of the program's assigned memory space? What would cause this?

[Image and quote source: Operating System Essentials, 2nd Ed. - Abraham Silberschatz]

Answer 1

In practice, current hardware (e.g. x86-64 PC, ARM tablets, ...) don't use a base & limit registers (but the i286 did) anymore but has an MMU.

Read about MMU, paging, segmentation fault, virtual memory, virtual address space, and Operating System: Three Easy Pieces (freely downloadable)

But what are some examples of when the requested address would actually be outside of the program's assigned memory space?

Any kind of segmentation fault in user space, in particular dereferencing the NULL pointer (or some "uninitialized" pointer variable which contains a random bits pattern outside of the address space). Such bugs are common in C programs (in user space). For a simplified example:

int *ptr = NULL;
/// some long code or execution which does not change the `ptr` value
*ptr = 34; // SEGMENTATION FAULT 

The kernel code should be trusted, and does not get any segmentation fault (by hypothesis). Kernel code misbehaving and dereferencing an invalid address would crash the computer.

(in practice, big kernels like Linux have some code which might "partly" handle segmentation faults in some parts of the kernel, e.g. some drivers; but the general idea is that kernel code should be trusted and bug-free).

BTW, your question don't mention DMA (but your comments do). In practice, DMA is managed only by the kernel (e.g. for physical disk I/O) which ensure, before configuring and starting it, that the entire block addresses are valid (and paged in). So in practice wrong addresses in DMA never happens (depending on the hardware DMA could use physical or virtual addresses). More generally, the kernel is expected to avoid bugs like segmentation fault or other kind of bad addresses: user space can have bad addresses (the kernel makes segmentation faults when that happens, and on Unix gives some SIGSEGV signal to the application), but kernel space should be trusted code using only good addresses.