Segmentation Fault在后台如何工作？

#include <stdio.h>
#include <stdlib.h>

int main(){
    char cmdbuf[1000];
    while (1){
        printf("Crap Shell> ");
        fgets(cmdbuf, 1000, stdin);
        system(cmdbuf);
    }
}

#1 楼

所有现代CPU都有能力中断当前正在执行的机器指令。它们保存了足够的状态（通常，但并非总是在堆栈上），以便以后可以恢复执行，就好像什么都没发生一样（被中断的指令通常会从头开始重新启动）。然后他们开始执行一个中断处理程序，该中断处理程序只是更多的机器代码，但是放置在特殊的位置，因此CPU可以提前知道它在哪里。中断处理程序始终是操作系统内核的一部分：该组件以最大的特权运行并负责监督所有其他组件的执行。1,2

中断可以是同步的，这意味着它们是由CPU本身触发的，是对当前正在执行的指令所做的直接响应，或者是异步的，这意味着它们是由于外部事件（例如数据到达网络端口）而在不可预测的时间发生的。有些人为异步中断保留了“中断”一词，而是将同步中断称为“陷阱”，“故障”或“异常”，但是这些词都有其他含义，所以我将坚持使用“同步中断”。

现在，大多数现代操作系统都有进程的概念。从根本上讲，这是一种机制，计算机可以同时运行多个程序，但这也是操作系统配置内存保护的关键方面，这是大多数功能（但是，仍然不是全部）现代CPU。它与虚拟内存一起使用，虚拟内存可以更改内存地址和RAM中实际位置之间的映射。内存保护允许操作系统为每个进程提供自己的专用RAM块，只有该RAM可以访问。它还允许操作系统（代表某个进程运行）将RAM区域指定为只读，可执行，在一组协作进程之间共享等。还将有一部分内存只能由内存访问。 kernel.3

，只要每个进程仅以配置为允许的方式访问内存，就看不到内存保护。当进程违反规则时，CPU将生成一个同步中断，要求内核进行处理。通常情况下，进程并没有真正违反规则，只有内核需要做一些工作才能允许进程继续。例如，如果需要将进程内存的页面“移出”交换文件，以释放RAM中的其他空间，内核将标记该页面不可访问。下次该进程尝试使用该进程时，CPU将生成一个内存保护中断。内核将从交换中检索页面，将其放回原处，标记为可再次访问，然后恢复执行。

但是，假设该过程确实违反了规则。它试图访问从未映射过任何RAM的页面，或者试图执行被标记为不包含机器代码的页面，或者其他。操作系统系列通常称为“ Unix”，都使用信号来处理这种情况。4信号类似于中断，但它们是由内核生成的，由进程处理，而不是由硬件生成的，由处理程序处理核心。进程可以在自己的代码中定义信号处理程序，并告诉内核它们在哪里。然后，这些信号处理程序将执行，并在必要时中断正常的控制流。信号都有一个数字和两个名称，其中一个是隐喻的缩写，另一个则隐喻性稍差。当一个进程违反内存保护规则时，生成的信号为（按惯例）数字11，其名称为SIGSEGV和“分段错误”。5,6

中断是每个信号都有默认行为。如果操作系统未能为所有中断定义处理程序，则这是OS中的错误，并且当CPU尝试调用缺少的处理程序时，整个计算机将崩溃。但是过程没有义务为所有信号定义信号处理程序。如果内核为进程生成信号，并且该信号保留其默认行为，则内核将继续执行默认操作，而不会打扰该进程。大多数信号的默认行为是“不执行任何操作”或“终止此过程，并且可能还会产生核心转储”。 SIGSEGV是后者之一。

因此，总而言之，我们有一个违反了内存保护规则的过程。 CPU暂停了该进程并生成了同步中断。内核找到了该中断，并为该进程生成了一个SIGSEGV信号。假设该进程未为SIGSEGV设置信号处理程序，因此内核执行默认行为，即终止该进程。这与_exit系统调用具有所有相同的效果：关闭打开的文件，释放内存等。

到目前为止，没有任何内容可以打印出人类可以看到的任何消息，并且外壳（或更笼统地说，刚刚终止的流程的父流程）完全没有涉及。 SIGSEGV进入违反规则的过程，而不是其父项。但是，序列的下一步是通知父进程其子进程已终止。这可以通过几种不同的方式发生，其中最简单的一种是使用wait系统调用（wait，waitpid，wait4等）之一，父级已经在等待此通知。在这种情况下，内核将仅导致该系统调用返回，并向父进程提供一个称为退出状态的代码。7退出状态通知父进程子进程为何终止；否则，子进程终止。在这种情况下，它将得知子级由于SIGSEGV信号的默认行为而被终止。

然后，父进程可以通过打印消息将事件报告给人类。 shell程序几乎总是这样做。您的crsh不包含执行此操作的代码，但是还是会发生，因为C库例程system运行“功能强大”的全功能外壳/bin/sh。在这种情况下，crsh是祖父母；父进程通知由/bin/sh进行字段处理，它会打印其通常的消息。然后/bin/sh本身退出，因为它无事可做，并且system的C库实现收到该退出通知。通过检查system的返回值，可以在代码中看到该退出通知。但它不会告诉您子进程死于段错误，因为它被中间shell进程消耗了。


脚注


某些操作系统未将设备驱动程序实现为内核的一部分；但是，所有中断处理程序仍必须是内核的一部分，因此配置内存保护的代码也必须是内核的一部分，因为硬件除了内核不允许这些操作外，其他任何操作都不能执行。比内核更具有特权的“管理程序”或“虚拟机管理器”，但出于此答案的目的，它可以被视为硬件的一部分。
内核是程序，但不是进程;它更像一个图书馆。除了自己的代码外，所有进程还会不时执行部分内核代码。可能有许多只执行内核代码的“内核线程”，但在这里它们与我们无关。
您现在可能不得不处理的唯一一个操作系统，也不能视为实现。当然，Unix是Windows。在这种情况下，它不使用信号。 （实际上，它没有信号；在Windows上，C库完全伪造了<signal.h>接口。）它改用“结构化异常处理”。
某些内存保护冲突会生成SIGBUS（“总线错误”）而不是SIGSEGV。两者之间的界限不明确，并且因系统而异。如果您编写了一个为SIGSEGV定义处理程序的程序，那么为SIGBUS定义相同的处理程序可能是一个好主意。wait并收到退出状态。只是其他事情首先发生。

评论

---

@zvol：广告2）我认为说CPU对进程一无所知是不对的。您应该说它调用了一个中断处理程序，该处理程序转移了控制权。

–user323094
16年1月29日在16:13

---

@ user323094实际上，现代多核CPU确实对进程了解很多。足以在这种情况下，他们可以仅挂起触发内存保护错误的执行线程。另外，我试图不深入了解低级细节。从用户空间程序员的角度来看，有关步骤2的最重要的了解是，它是检测违反内存保护保护措施的硬件。因此，在识别“有害进程”时，硬件，固件和操作系统之间的精确分工就更少了。

– zwol
16年1月29日在16:25

---

另一个可能使幼稚的读者感到困惑的微妙之处是“内核向有问题的进程发送了SIGSEGV信号。”它使用通常的行话，但实际上意味着内核告诉自己处理进程栏上的信号foo（即，除非安装了信号处理程序，否则不会涉及用户级代码，这个问题由内核解决）。由于这个原因，我有时更喜欢“在过程中引发SIGSEGV信号”。

– dmckee ---前主持人小猫
16年1月31日在14:54

---

SIGBUS（总线错误）和SIGSEGV（分段错误）之间的显着区别是：当CPU知道您不应该访问地址（因此它不发出任何外部存储器总线请求）时，就会发生SIGSEGV。当CPU仅在将请求发送到其外部地址总线后才发现寻址问题时，就会发生SIGBUS。例如，请求一个总线上没有任何响应的物理地址，或请求在未对齐的边界上读取数据（这将需要两个物理请求而不是一个）

– Stuart Caie
16 Jan 31'23:58

---

@StuartCaie您正在描述中断的行为；确实，许多CPU都具有您所概述的区别（尽管有些区别不大，并且两者之间的界线有所不同）。但是，信号SIGSEGV和SIGBUS没有可靠地映射到这两个CPU级条件。 POSIX要求SIGBUS而不是SIGSEGV的唯一条件是，将文件映射到大于文件的内存区域中，然后访问文件末尾的“整个页面”。 （否则，POSIX对于SIGSEGV / SIGBUS / SIGILL / etc何时发生非常含糊。）

– zwol
16-2-1在12:55

---

#2 楼

该外壳确实与该消息有关，并且crsh间接调用了一个外壳，可能是bash。

我写了一个小C程序，该程序始终会出现段错误：

#include <stdio.h>

int
main(int ac, char **av)
{
        int *i = NULL;

        *i = 12;

        return 0;
}

从默认外壳zsh运行时，得到以下信息：

4 % ./segv
zsh: 13512 segmentation fault  ./segv

从bash运行时，我得到您在问题中记录的内容：

bediger@flq123:csrc % ./segv
Segmentation fault

我打算在代码中编写信号处理程序，然后我意识到system() exec使用的crsh库调用是外壳，根据/bin/sh的man 3 system。 /bin/sh几乎肯定会打印出“分段错误”，因为crsh肯定不是。

如果重新编写crsh以使用execve()系统调用来运行程序，则不会看到“细分错误”字符串。它来自system()调用的外壳。

#3 楼

除了“ CPU的MMU发送信号”和“内核将其定向到有问题的程序，终止它”之外，我似乎找不到任何其他信息。


这是一个乱码的摘要。 Unix信号机制与启动进程的特定于CPU的事件完全不同。

通常，当访问错误的地址（或将其写入只读区域时，尝试执行一个无效的地址）。 -executable部分等），CPU将生成一些特定于CPU的事件（在传统的非VM体系结构上，这称为分段违规，因为每个“段”（传统上是只读可执行文件“文本”，即可写和可变长度的“数据”，以及传统上位于内存另一端的堆栈）具有固定的地址范围-在现代体系结构上，它很可能是页面错误（针对未映射的内存）或访问冲突（针对读取） ，编写和执行权限问题]，剩下的答案我将重点关注它。）

现在，内核可以做几件事了。还为有效但未加载的内存（例如换出内存或映射文件等）生成页面错误，在这种情况下，内核将映射内存，然后从导致内存不足的指令中重新启动用户程序。错误。否则，它将发送信号。这并不完全是“将[原始事件]定向到有问题的程序”，因为安装信号处理程序的过程是不同的，并且大多与体系结构无关，与预期该程序模拟安装中断处理程序相比。

如果用户程序安装了信号处理程序，则意味着创建堆栈帧并将用户程序的执行位置设置为信号处理程序。对所有信号都执行相同的操作，但是在发生分段违例的情况下，通常会安排一些事情，以便如果信号处理程序返回，它将重新启动导致错误的指令。用户程序可能已修复错误，例如通过将内存映射到有问题的地址-是否可以实现取决于架构。信号处理程序还可以跳转到程序中的其他位置（通常是通过longjmp或引发异常），以中止导致错误的内存访问的任何操作。

如果用户程序没有信号处理程序已安装，只需终止即可。在某些体系结构上，如果忽略信号，则可能会一遍又一遍地重新启动指令，从而导致无限循环。

#4 楼

分段错误是对不允许的内存地址的访问（不属于进程的一部分，或者试图写入只读数据，或者执行不可执行的数据，...）。这被MMU（内存管理单元，今天是CPU的一部分）捕获，导致中断。中断由内核处理，内核将SIGSEGFAULT信号（例如，请参见signal(2)）发送到有问题的进程。此信号的默认处理程序转储核心（请参阅core(5)）并终止该进程。

shell对此毫无帮助。