Fedora 和 Ubuntu 上的段错误

LilyBBS discussion: Segmentation Fault on Fedora and Ubuntu

昨天和别人在小百合 LinuxUnix 版发帖讨论 Segmentation Fault 的问题，整理如下：

flyDutchMan 根据自己存在段错误的程序在 Fedora 和 Ubuntu 上的运行结果，认为 Fedora 和 Ubuntu 对段错误的处理方式不同，他的观点是(原文链接：[href: http://bbs.nju.edu.cn/vd83468/bbscon?board=LinuxUnix&file=M.1185514732.A&num=6528 ] )：

“Ubuntu认为段错误是很严重的错误，它的做法是当即中断程序。而Fedora对待段错误是比较宽容的，在Fedora中即使检测到某个进程正在对不属于它的地址空间进行操作，他仍然会完成这次“非法”的操作，并且继续执行后面的操作，只是在终端上打印出“Segment Fault”的错误。所以在这个程序中，虽然发生了段错误，Fedora仍然能运行到connect()，是整个程序顺利跑起来。”

并给出了一个 demo：

#include <stdio.h>

#define IP_ADDR_LENGTH 16
#define UMP_FUNC_NUM 6

int main() {
  char addr[IP_ADDR_LENGTH];
  addr[0] = '';
  strcat(addr, "172.16.64.181" );

  char (*taskpath)[IP_ADDR_LENGTH];

  printf("the address is %dn", &amp;taskpath[0]);

  int a;
  int b;

  sprintf(taskpath[0], "%s", addr);

  printf("taskpath[0]: %sn", taskpath[0]);
  printf("finish!n");
  fflush(stdout);

  return 0;
}

“在Ubuntu下运行，系统不会输出“ finish！ ”这句，而是在输出taskpath[0]的地址后直接终止程序。注意，上面的int a; int b;声明不能省略，也不能赋值！因为如果省略或赋值，就不会产生Segment Fault！（赋值的话系统就会把这两个变量分配到Stack中，这就与对Heap操作的taskpath没有冲突了）”

我的回复是(原文链接：[href: http://bbs.nju.edu.cn/vd83468/bbscon?board=LinuxUnix&file=M.1185532985.A&num=6538 ])：

首先，我的观点，没有所谓 Fedora 和 Ubuntu 对段错误处理的不同。因为它们都是使用 Linux kernel，而内存管理只要 Kernel 的版本一样，我认为不会有不同的处理方式。

其次，我想纠正上文中的一个说法(可能有些讨人嫌哈，不过一些东西还是说清楚点儿好，因为 ls 用这个来解释自己的程序)：

> 赋值的话系统就会把这两个变量分配到Stack中，这就与对Heap操作的taskpath没有冲突了

无论你赋值与否，这两个变量都是存在在 stack 中的； taskpath 也不是对 heap 进行操作，它只是存在于 stack 上的一个指针变量。

> 因为如果省略或赋值，就不会产生Segment Fault！

在我的系统中，都会产生段错误。

最后，我来给出我对这个问题的解释：

就上文的 demo 程序来说, a, b, addr, taskpath 都是存在于 stack 上的，这个很清楚，调试过 C 语言程序的人应该都知道，我就不解释了。

1. 为什么会出现段错误?

因为 taskpath 是一个野指针，在使用之前没有被赋值，所以 taskpath 会指向任何位置，对一个随机的位置进行写操作，显然会出现段错误。

2. 为什么同一个程序，定义不定义 a, b 会影响段错误出来的时间点？

虽然上面说 taskpath 会指向任何位置，但是这个说法并不完全正确。因为大家知道，taskpath 是在 stack 上的一个变量，而 stack 呢，是一直在重复使用的一个区域。要明确这一个概念，在操作系统中执行一个可执行文件，程序并不是从 main 开始的，它要先执行一段代码，也就是平常所说的 crt(c runtime)。这个一般是由 lib 提供的，其中要调用一些库函数，所以呢，在 main 执行之前， stack 被 crt 用过（这是最关键的一点）。

因为 stack 使用完是会被释放的，这也就是在调用函数时 function prologue 和 epilogue 所干的事情，开辟栈空间和恢复栈空间，主要动作就是移动栈指针。那么 taskpath 所占的位置很有可能被 crt 用过（不是一定），那么如果被 crt 写过，比如被 crt 用做保留 ebp 或者什么其他的寄存器，它的值就是确定的（在一定程度上说）。

如果 crt 在 taskpath 这个位置上保存过寄存器的值，尤其是 ebp 或者 esp，那么很有可能 taskpath 就指向此程序栈空间的某个位置。那么写 taskpath 指向的内存产生的段错误就没那么 critical，或者说操作系统对它的指针在自己栈空间中的操作比较容忍，就不会立即停止程序的运行。但是如果 crt 没有在这个位置上进行操作，那么这个位置就可能是某个垃圾地址，比如说操作系统自己的内存空间，那么写 taskpath 指向的内存就会造成很严重的后果，操作系统会立马检查出来终止它的运行。

我在 Ubuntu 7.04 下使用 gcc 4.1.2 编译、调试并反汇编的结果显示：两个程序唯一的不同是 taskpath 在堆栈上的位置，当定义 int a, b; 时，taskpath 是 $ebp -40 而这个地址没有被操作过；当不定义 int a, b; 时， taskpath 是 $ebp - 32，这个地址曾经被 crt 使用过。所以按照上面的解释，系统报段错误的时间不一样。

如果熟悉 GDB 的话，可以很容易的用调试证明这一点。计算出 crt 入口的 $ebp 和 main 中 $ebp 的差，以此计算出 taskpath 保存的位置，在上面设置 watch point，从 _init 执行到 main，看其中有没有对 taskpath 所在位置进行写操作。

3. 为什么不同的操作系统，结果不一样？
这个就比较简单了。kernel 不一样，可能内存管理的方式不一样。使用的 lib 或者 gcc 不一样，可能引起 crt 的汇编结果不一样。这两个都能导致同样的程序报错的时间不一样。

所以，不是 Fedora 或者 Ubuntu 能不能容忍段错误，没有 OS 容忍段错误，不同只是在产生段错误够不够 crucial 需要得到立即处理。