简而言之就是访问了错误的内存段或者是0地址。

一、表现/现象

在Eclipse的输出框或者Linux终端调用运行的时候报出xxxxx文件的某一行有一个segment error/fault

这个问题属于比较棘手和麻烦的问题，因为像这个内存报错问题在VS下一般不会有问题，在Linux下才会无法运行。

需要注意的是，报错信息里面的xxxx文件的xxx行出现了段错误也不一定是准确的，因为此时程序已经跑飞了，所以报的错可能风马牛不相及，还是要从上次稳定运行的代码到这次的代码中的增加的代码入手，所以下面提供一些可能的原因，方便从代码入手排除错误

二、可能的原因

2.1 内存访问越界

1. 由于使用错误的下标，导致数组访问越界，我最早遇到这个问题就是这样的，我计算的数组大小和实际的有偏差，设置的小了一点，Visual Studio下没有问题，一旦到eclipse下编译运行就会直接闪退
2. 搜索字符串时，依靠字符串结束符来判断字符串是否结束，但是字符串没有正常的使用结束符
3. 使用strcpy, strcat, sprintf, strcmp, strcasecmp等字符串操作函数，将目标字符串读/写爆。应该使用strncpy, strlcpy, strncat, strlcat, snprintf, strncmp, strncasecmp等函数防止读写越界。 数组开小了 我曾在这地方吃过亏了

2.2 多线程未加锁

程序使用了线程不安全的函数，多线程读写的数据未加锁保护。
对于会被多个线程同时访问的全局数据，应该注意加锁保护，否则很容易造成core dump

2.3 非法指针

1. 使用空指针
2. 随意使用指针转换。一个指向一段内存的指针，除非确定这段内存原先就分配为某种结构或类型，或者这种结构或类型的数组，否则不要将它转换为这种结构或类型的指针，而应该将这段内存拷贝到一个这种结构或类型中，再访问这个结构或类型。这是因为如果这段内存的开始地址不是按照这种结构或类型对齐的，那么访问它时就很容易因为bus error而core dump.

2.4 堆栈溢出.

不要使用大的局部变量（因为局部变量都分配在栈上），这样容易造成堆栈溢出，破坏系统的栈和堆结构，导致出现莫名其妙的错误。

三、排查的方法

网上也有一些像是通过core文件来判断错误的方法，Linux下的C程序常常会因为内存访问等原因造成segment fault（段错误），如果此时core dump 的功能是打开的，在运行我们的可执行程序时就会生成一个名为core的文件，然后我们就可以用gdb对core文件来进行调式，还原发生错误的堆栈情况例如上面的这两篇文章。

但我觉得这种方法并不直观，而且操作起来也过于复杂，所以下面从代码的角度提供一种判断问题的思路。

上面已经说过，由于内存读取段错误的时候，程序已经跑飞了，所以报错的文件实际上不一定是真正有问题的文件（大概率不是），所以我们确定有问题的代码应该是从上一次更新到这一次准备提交之间的代码。针对从代码的角度找错误，有直接法和间接排除法两种方法：

3.1 直接法：

根据当前新增代码，检查是否有类似设置的数组大小过小而导致越界情况错误的出现，如果代码段中有符合上述原因的相关片段，则要提高警惕，主动检查，如果不确定数组大小设置是否合适，可以主动扩大数组容量进行测试。

3.2 间接排除法：

1. 如果直接法没有找到错误原因的话，可以分段屏蔽掉新增的代码，如果哪一段屏蔽之后不再出现段错误，则证明该段内部有问题。
2. 在该段内部，可以添加一段打印信息（例如打印一串星号“*************”），然后把这个打印信息放在可能出现问题的语句的下面，当我们发现报错的出现但是控制台并没有打印出星花的时候，则说明在打印信息代码的上面出现了内存报错
3. 逐步将打印信息的代码向上提，直到打印信息出现在报错之前，即可确定错误语句的位置，也就可以根据上面的原因进行对应的修改
   

需要注意的是：
由于内存错误的特殊性，很有可能测试的结果会有一定的误差，即：有错误的代码也有可能偶尔一次表现正确，这样就为我们定位错误又增加了一些难度，因为有可能屏蔽掉当前代码这次没出错，下次出错了。但是只要代码是有问题的，大概率都会出错。为了应对这种情况，我们应该：在屏蔽掉每段代码或者增加了相关打印信息之后，多测试几遍效果（2-3遍），确定是否必发，以确保我们得到的排查方向是准确的

如果大家发现本文还有需要补充或者不会准确的地方，欢迎交流！