1. Segmentation fault (core dumped)原因

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文件

使用gdb 调试方法，首先要在gcc编译时加入-g选项。

在程序崩溃后在目录中会产生core.xxxx文件，core文件中包含着出错信息。
如果没有core文件，是因为系统设置了core文件大小为0。
通过命令ulimit -a即可查询到。
在执行ulimit -c unlimited命令后，core文件大小就不受限制。
此时再次运行程序后目录中出现core.xxxx文件。
用gdb ./file core.xxxx可查看出错所在行信息了。其中file为原执行的程序名。
这样进入了gdb core调试模式。

追踪产生segmenttation fault的位置及代码函数调用情况：
gdb>bt
这样，一般就可以看到出错的代码是哪一句了，还可以打印出相应变量的数值，进行进一步分析。

gdb>print 变量名
之后，就全看各位自己的编程功力与经验了，gdb已经做了很多了。

使用valgrind调试工具

对于结构复杂的程序，如涉及模板类及复杂的调用，gdb得出了出错位置，似乎这还不够，这时候要使用更为专业的工具——valgrind。

valgrind是一款专门用作内存调试，内存泄露检测的开源工具软件，valgrind这个名字取自北欧神话英灵殿的入口，不过，不能不承认，它确实是Linux下做内存调用分析的神器。一般Linux系统上应该没有自带valgrind，需要自行进行下载安装。

yum -y install valgrind

安装成功后，使用类似如下命令启动程序：

valgrind --tool=memcheck --leak-check=full --track-origins=yes --leak-resolution=high --show-reachable=yes --log-file=memchecklog ./controller_test

其中，–log-file=memchecklog指记录日志文件，名字为memchecklog；–tool=memcheck和–leak-check=full用于内存检测。

可以得到类似的记录：

23735
23735 Thread 1:
23735 Invalid read of size 4
23735 at 0x804F327: ResourceHandler::~ResourceHandler() (ResourceHandler.cpp:48)
23735 by 0x804FDBE: ConnectionManager::~ConnectionManager() (ConnectionManager.cpp:74)
23735 by 0×8057288: MainThread::~MainThread() (MainThread.cpp:73)
23735 by 0x8077B2F: main (Main.cpp:177)
23735 Address 0×0 is not stack’d, malloc’d or (recently) free’d
23735

可以看到说明为无法访问Address 0x0，明显为一处错误。

这样valgrind直接给出了出错原因以及程序中所有的内存调用、释放记录，非常智能，在得知错误原因的情况下，找出错误就效率高多了。

再说一句，valgrind同时给出了程序的Memory Leak情况的报告，给出了new-delete对应情况，所有泄漏点位置给出，这一点在其他工具很难做到，十分好用。

4. 使用gdb调试程序

如上述流程不能解决问题，下面可使用gdb单步调试程序。重新编译程序，编译命令中加入-g。如：

gcc -lm -O3 -g file.c -o file
之后使用gdb命令

gdb file
开始调试。

输入start使程序运行到main中第一行运行代码。next或者n为执行下一行程序，until xx执行到xx行，print或p可输出变量值，b xx用于在xx行设置断点，run或r用于执行程序至下一断点，d xx删除xx行断点。

我们可以先run一遍程序，这时它会提示出错行信息。然后until到出错行前5行，交替执行next和print，输出与出错行变量相关变量或指针的值。最终定位出错的根本操作在哪一行。修改之即可。