Segmentation fault protection

Segmentation fault protection is a draft programming task. It is not yet considered ready to be promoted as a complete task, for reasons that should be found in its talk page.

A segmentation fault or segfault is an error that your computer will raise if a program attempts to access memory that it's not supposed to, for example, trying to write to executable code or read-only memory, dereferencing a null pointer, etc. Often this happens when an array is indexed out-of bounds, such as (for example) trying to read element 500 of an array with only 6 entries (see the pseudocode example below):

myArray = {1,2,3,4,5,6};
myVariable = myArray[500];        //causes a segfault

Although this seems like a silly example, it's a lot more common than those who are new to programming may think, and different languages have different safeguards in place for preventing this kind of thing from happening. Some languages would refuse to compile the above example, some will give you a warning and run anyway, and others may not even care at all.

Task

Showcase what built-in protections your language has for segmentation faults, if any. If your language doesn't have any, show what happens when your program commits a segmentation fault. (Be safe and don't destroy your computer!)

6502 Assembly The 6502 doesn't have any handlers for access violation; the entire address space of the CPU is fair game. As you can imagine this isn't good for computer security.

However, the stack being fixed at $0100-$01FF means that the stack will never overwrite the heap, yet it can get to the point where new values pushed onto the stack overwrite the old, which can cause a CPU crash if you try to unwind the stack back to the beginning.

The 6502 uses memory-mapping to interact with external hardware, and reading/writing a memory location you normally shouldn't because your array indexed out of bounds can cause issues with external hardware, and even on some systems can result in a killer poke which can damage certain machines such as the Commodore PET. Memory-mapped ports don't work like normal memory; unlike normal memory, even reading a memory-mapped port can affect its contents, or affect the contents of other ports that are related to that hardware. (This isn't a property of the 6502 itself, but of the hardware connected to it.)