Then they start executing an interrupt handler, which is just more machine code, but placed at a special location so the CPU knows where it is in advance. They save enough state (usually, but not always, on the stack) to make it possible to resume execution later, as if nothing had happened (the interrupted instruction will be restarted from scratch, usually). How does 'Segmentation fault' even get printed? 'Who' is doing it? The kernel? Something else? How does the signal and all of its side effects propagate from the hardware to the eventual termination of the program?Īll modern CPUs have the capacity to interrupt the currently-executing machine instruction. I've just demonstrated that it's not the shell that does this, but the system underneath. If my assumptions were correct, this would either a) crash crsh, closing the xterm, b) not print 'Segmentation fault', or c) both. Then I proceeded to run a program that produces a segfault.

So I ran this shell in a bare terminal (without bash running underneath). This shell does not do anything except take user input and feed it to the system() method. So I tested that assumption by writing an extremely minimal shell I call crsh (crap shell).

I assumed that it probably sends the signal to the shell and the shell handles it by terminating the offending process and printing 'Segmentation fault'. I can't seem to find any information on this aside from 'the CPU's MMU sends a signal' and 'the kernel directs it to the offending program, terminating it'.

Cmus segmentation fault