Linux程序运行出现Segmentation fault (core dumped)的通用解决方法

之前v4l-test编译后运行时出现错误Segmentation fault (core dumped)，段错误（核心已转储），因为代码不同，错误原因不一样，导致解决方法也不一样，所以找了许多都没有找到好的解决方法，最终在一篇博客发现这类问题的通用解决方法，博客地址如下：

https://www.cnblogs.com/kuliuheng/p/11698378.html

1 问题原因

         Segmentation fault (core dumped)多为内存不当操作造成。空指针、野指针的读写操作，数组越界访问，破坏常量等。对每个指针声明后进行初始化为NULL是避免这个问题的好办法。排除此问题的最好办法则是调试。

更为详细的原因：

（1）内存访问越界

a) 由于使用错误的下标，导致数组访问越界
b) 搜索字符串时，依靠字符串结束符来判断字符串是否结束，但是字符串没有正常的使用结束符
c) 使用strcpy, strcat, sprintf, strcmp, strcasecmp等字符串操作函数，将目标字符串读/写爆。应该使用strncpy, strlcpy, strncat, strlcat, snprintf, strncmp, strncasecmp等函数防止读写越界。

（2）多线程程序使用了线程不安全的函数。

（3）多线程读写的数据未加锁保护。

      对于会被多个线程同时访问的全局数据，应该注意加锁保护，否则很容易造成core dump

（4）非法指针

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

（5）堆栈溢出。

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

2 使用GDB查看core文件

 1，默认编译出来的程序在出现Segmentation fault 时并没有生成core崩溃文件，可以在gcc/g++编译时增加-g选项。

         例如：cc -O2 -Wall -Wextra -g  -c -o test_VIDIOC_ENUMSTD.o test_VIDIOC_ENUMSTD.c

2，如果仍然没有生成core文件，则可能是因为系统设置了core文件大小为0，可以通过：ulimit -a 查询得知。执行 ulimit -c unlimited 命令后可以使core文件大小不受限制。此时再次运行程序应该就能在同级目录看到core文件了

3，使用 gdb ./运行文件 core 可以查看出错所在行信息，这样就进入了 gdb core 调试模式。

追踪产生segmenttation fault的位置及代码函数调用情况：

（gdb）bt

使用（gdb）Quit退出。

4，进行分析，可以明显看出我是在v4l2_test.c的410行出了问题，再往里就是cunit的调用栈了， 我们看不到行号，好像得有那个so的调试信息才可以，目前还不会在gdb里动态挂符号文件 ，所以就先不管了，输入q退出调试器，其它命令用输入help学习下。

就调用了一个CU_register_suites函数，函数本身应该没有错误，可能是传给他从参数 有问题，就是那个suites，该参数构建的代码如下：

是个CU_SuiteInfo的数组，感觉可能是构建这个类型没构建对，然后就看他在哪儿定义 的:

可以看到，在TestDB.h的712，代码如下：

通过代码可以看到，该结构有6个成员，而之前的suites里面有4个参数，所以根据定义修改添加就好了。

修改之后重新编译就可以运行了。