Fedora 和 Ubuntu 上的段错误

目录 Linux

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 需要得到立即处理。

长按识别二维码关注《边际效应》
长按识别二维码关注《边际效应》

5 条评论

  • Zhaoyu
    2007-08-05

    这个貌似专业了 不懂的说~

  • wangcong
    2007-08-05

    line 10: warning: implicit function declaration: strcat
    =============================================
    (10) warning: implicit function declaration: strcat
    (14) warning: variable may be used before set: taskpath

    variable unused in function
    (16) a in main
    (17) b in main

    function returns value which is always ignored
    fflush printf sprintf strcat

    function argument ( number ) type inconsistent with format
    printf (arg 2) char (*)[] :: (format) int test.c(14)

  • wangcong
    2007-08-05

    从堆栈情况来看,taskpath的内容应该是"172.16.64.181"的地址。
    这只是i386上的一个巧合。

  • Solrex Yang
    2007-08-06

    [Comment ID #133318 Will Be Quoted Here]

    这个警告我也遇到了,只不过这是引用别人的源程序,所以就原文没改....

    [Comment ID #133370 Will Be Quoted Here]
    taskpath 并不一定都会巧合的,当字符串拷贝过后,只要系统允许它使用 taskpath 指向的空间,肯定是 "172.16.64.181" 啊!

  • wangcong
    2007-08-06

    我的意思是还涉及压栈的顺序,先入栈的是"172.16.64.181",然后才是addr。

发表评论

电子邮件地址不会被公开。 必填项已用*标注