理解 Segmentation fault

在Linux下动态共享库被当作可执行文件来处理，虽然它不能单独执行，但某些应用程序的运行离不了它。
   最后是可执行文件，这个就不用多说了，看图：

 

 

    
   所以，我们可以得到这样一个结论：一个具体的ELF文件，其文件头部中的某些属性值，指明了它到底是可执行文件还是可重定位文件(*o和*.so的统称)。这样，链接器和装载器通过分析ELF文件头部就可以知道它该怎么处理该文件了。用比较直观的、方便理解的图来表示它们的区别就是：

 

 

    
   也就是说链接的时候Program Header Table是可选的，但Section Header Table是必须有的。例如*.o就没有Program Header Table，而*.so就有。装载的时候Program Header Table必须有，但Section Header Table是可选的，但即使有Section Header Table，装载器也不会鸟它。

   那么，装载器为什么要采取和链接器不同的处理策略呢？最主要的原因是为了提高内存的利用率。现代操作系统在装载程序时都充分利用程序的局部性原理，那就是，当进程运行时，并不需要一下子将程序的所有代码和数据都装载到内存里，而是先装载程序的一部分到内存里运行。当进程将要执行的指令不在内存里的话，CPU便会触发一个缺页异常，操作系统捕获到这样的异常后便接管进程，然后将需要的指令“弄”到内存里，再将执行权限还给进程。

   进程运行的时候，它虚拟地址空间的布局和它所占用的物理内存到底是什么样子呢？虚拟地址空间我们还比较好理解，可实际物理地址并不是我们能直接访问到的。一般是通过一个集成在CPU内部的叫做MMU的内存管理单元完成了从进程虚拟地址到物理地址之间的映射。对这个映射过程感兴趣的童鞋可以去拜读Bean_lee兄的“Linux 从虚拟地址到物理地址”文章，那是相当之精彩。如果看不懂，就随时咨询他老人家。不过据我所知，他最近有点忙，忙得不亦乐乎，呵呵。OK，回到我们的话题上来。既然进程虚拟地址空间的任何地址，在使用前都必须通过MMU将其映射到物理内存上一个实实在在的存储单元上。那么对于任何没有经过MMU映射过的虚拟空间的地址，不管进程是执行写操作还是读操作，操作系统都会捕捉到这个错误的非法访问，然后输出一个“Segmetation Fault”的错误提示信息并强行终止进程。

   换句话说，一个进程虚拟空间里的任何地址，在进程访问它之前必须要经过MMU转换，将它映射到物理内存的某个具体的存储位置上才是合法有效的，不然操作系统就会用“Segmetation Fault”对你的进程进行宣判，然后将其kill掉。那么，问题又来了，到底哪些地址才是合法有效的呢？看一个简单的进程虚拟地址空间的布局：

 

 

1、0x084800以前的地址、0xC0000000以后的地址：由于权限的问题，不允许进程直接访问，操作系统对其进行保护。所以用户进程如何访问它们的话就会触发“Segmetation Fault”的错误。前面几篇博文有如何访问0xC0000000以后地址的博文，也就是用户空间和内核空间的通信问题。

2、free地址段的空间就是前面说的，由于没有经过MMU将其映射到物理内存的实际存储单元上，当程序访问System break(也就是常说的brk)之后的地址就出引发段错误。brk一般是进程堆空间结束的地方。那么，我们如何知道当前进程的brk在什么地方呢？答案就是通过一个C库函数sbrk()来获取。另外还有一个系统调用brk()用来设置System break的位置，其实sbrk()也可以设置，它只不是对brk()系统调用的一个封装而已。关于这两个函数的更多用法可以参考man手册。

   为了不影响我们的测试效果，我们需要将内核的随机地址保护模式关掉。为了方式溢出攻击，现代很多操作系统都做了这样的随机地址保护。就是，当程序运行时，代码段、堆栈段的装载起始地址并不是固定不变的，而是每次运行进程时都会加上一个随机的偏移量，这会影响我们的测试效果。关闭它的方法很简单：

    [root@localhost ~]#echo "0" > /proc/sys/kernel/randomize_va_space

    如果/proc/sys/kernel/randomize_va_space为0则表示，进程每次启动运行时，其虚拟地址空间里的值就是它在ELF文件里所指定的值；如果为1，则每次启动时只有栈的装载地址做随机保护；如果为2，表示进程每次启动时，进程的装载地址、brk和堆栈地址都会随机变化。看个例子，这是网上流传比较多的一段代码，很具有代表性，这里我又站在前人的肩膀上了：

 

 

　　另一方面，内存分配时是以页为单位，一般页大小为4096字节，所以从0x08048000开始是代码段，共占内存0x00628，即1576个字节，不足一个页，但必须以页为单位，所以下一个页，也就是数据页必须从0x0804900开始。但上面显示却说数据页从0x08049628开始，但注意最后一列Allign，指明了对其方式，正好是4096字节。验证一下：

　　   这里我们看到操作系统确实是以页(4096字节)为单位进行内存分配。有些人可能觉得奇怪，既然stack都已经有了，为什么没有heap呢？原因是，默认情况，.bss段结束地址就是heap的开始地址。当源代码中没有诸如malloc()之类的动态内存分配函数时，在查看进程的内存映射时是看不到heap的。此时的进程空间的布局应该如下：

 

 

    我们可以知道，当程序访问0x0848000～0x0849FFF之间的所有数据都是OK的，当访问到0x084A000及其之后的地址就会报“Segmetation Fault”，因为我们的brk刚好到这里。不信？？好吧，把上面程序简单调整一下：

    重新编译运行memlayout，最后出现“Segmetation Fault”时应该是下面这个样子：

 

　　当你的源代码中有用到诸如malloc()之类的动态内存申请函数时，brk的值会被相应的往高端内存的位置进行调整，这样调整出来的一段内存就被所谓的内存管理器，也就是著名的buddy system纳入管理范围了。这样当我们再访问这些地址时，就不会报“Segmetation Fault”了。其实如果你看过Glibc源码你就会惊奇的发现，malloc()最终也是通过调用brk()

系统掉用来实现堆的管理。所以，如果我们把上述代码再做一下简单修改：

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int bssvar;
int main(int argc,char** argv)
{
        void *ptr;
        printf("main start = %p\n",main);
        printf("bss end = %p\n",(long)&bssvar+4);
        ptr=sbrk(0);
        printf("current brk = %p\n",(long*)ptr);
        sleep(8);
        int i=0x08049628;
        brk((char*)0x804A123); //注意这行代码
        for(;;i++)
                printf("At:0x%x-0x%x\n",i,*((char*)i));
}

我们用brk()系统调用，手动把brk调整到0x804A123处，再编译运行，你就会得到下面这样的结果：

至于是为什么不在0x804A123处报“Segmetation Fault”而是要跑到0x804B000处才报，原因已经不止一次的强调了，脑袋犯迷糊的童鞋还是从头再认真看一遍吧。

   又到了该总结的时候了，可能有些童鞋都忘了这篇博文是要讨论什么话题了：
   程序之所以会时不时的出现“Segmetation Fault”的根本原因是进程访问到了没有访问权限的地方，诸如内核区域或者其0x08048000之前的地方，或者由于要访问的内存没有经MMU进行映射所导致。而这种问题比较多的是出在malloc()之类的动态内存申请函数申请完内存，释放后，没有将指针设置为NULL，而其他地方在继续用先前申请的那块内存时，由于内存管理系统已经将其收回，所以才会出现这样的问题。良好的关于指针的使用习惯是，使用之前先判断其是否为NULL，所有已经归还给操作系统的内存，其访问指针都要及时置为NULL，防止所谓的“野指针”到处飞的情况，不然在大型项目里，光是围剿“Segmetation Fault”就要耗费不少兵力。