文章目录
呵，段错误？自从我看了这篇文章，我还会怕你个小小段错误？
请打开你的Linux终端，跟紧咯，准备发车！！嘟嘟嘟哒~~
①一段有段错误的代码
#include<stdio.h>
void errfunc()
{
int *p = NULL;
*p = 1;
}
int main()
{
errfunc();
return 0;
}
这段代码拿去运行，肯定段错误。
②跟我一起 -> 直达病灶
系统会在程序崩溃的那一刹那将整个内核的信息记录在一个文件里边。如果你是第一次，那么ls是查不到的。
这样：使用命令 ulimit -a 打开ulimit这个文件。会看到如下：
发现这个文件大小缺省为0，文件根本就装不进去，那么就需要我们手动将这个文件的大小改大一点：ulimit -c 10240，当然，可以设置别的大小，看你心情。
然后再运行一次段错误的文件，然后去ls，就会发现一个core.xxxx的文件，这里提醒一下，最好先ls，看看系统下有没有已存在的core文件，省的到时候不知道是哪个。
接下来有一步可走可不走的：可以使用命令 file core.4377(我测试的号码是这个) ，将core.4377这个文件的具体信息给显示出来，命令最后会显示这个core文件是通过哪个文件产生的。
最后一步：gdb调试。这个执行文件叫dcw,是我的。gdb dcw core.4377,就会看到如下：
在最后，它会告诉你，在那个函数、那个地址出了问题。有些比较高级的gdb甚至会告诉你是哪一行！！可惜我的gdb就不说。。。
哈哈，开个玩笑。
注意：调段错误，编译的时候一定要加入-g选项，要不然在最后显示错误的时候只会显示错的地址，而不会显示错误的具体信息
最后退出gdb调试：q，回车。
③看我对症下药
段错误的原因无非是内存越界，据不完全统计，主要有以下这些情况：
1 使用非法的内存地址（指针），包括使用未经初始化及已经释放的指针、不存在的地址、受系统保护的地址，只读的地址等，这一类也是最常见和最好解决的段错误问题，使用GDB print一下即可知道原因。
2 内存读/写越界。包括数组访问越界，或在使用一些写内存的函数时，长度指定不正确或者这些函数本身不能指定长度，典型的函数有strcpy(strncpy)，sprintf(snprint)等等。
3 对于C++对象，应该通过相应类的接口来去内存进行操作，禁止通过其返回的指针对内存进行写操作，典型的如string类的c_str()接口，如果你强制往其返回的指针进行写操作肯定会段错误的，因为其返回的地址是只读的。
4 函数不要返回其中局部对象的引用或地址，当函数返回时，函数栈弹出，局部对象的地址将失效，改写或读这些地址都会造成未知的后果。
5 避免在栈中定义过大的数组，否则可能导致进程的栈空间不足，此时也会出现段错误，同样的，在创建进程/线程时如果不知道此线程/进程最大需要多少栈空间时最好不要在代码中指定栈大小，应该使用系统默认的，这样问题比较好查，ulimit一下即可知道。这类问题也是为什么我的程序在其他平台跑得好好的，为什么一移植到这个平台就段错误了。
6 操作系统的相关限制，如：进程可以分配的最大内存，进程可以打开的最大文件描述符个数等，在Linux下这些需要通过ulimit、setrlimit、sysctl等来解除相关的限制，这类段错误问题在系统移植中也经常发现，以前我们移植Linux的程序到VxWorks下时经常遇到（VxWorks要改内核配置来解决）。
7 多线程的程序，涉及到多个线程同时操作一块内存时必须进行互斥，否则内存中的内容将不可预料。
8 在多线程环境下使用非线程安全的函数调用，例如 strerror 函数等。
9 在有信号的环境中，使用不可重入函数调用，而这些函数内部会读或写某片内存区，当信号中断时，内存写操作将被打断，而下次进入时将无法避免地出错。
10 跨进程传递某个地址，传递的都是经过映射的虚拟地址，对另外一个进程是不通用的。
11 某些有特殊要求的系统调用，例如epool_wait，正常情况下使用close关闭一个套接字后，epool会不再返回这个socket上的事件，但是如果你使用dup或dup2操作，将导致epool无法进行移除操作，此时再进行读写操作肯定是段错误的。
加油啦，一定是可以实现的啦！！