Segmentation fault 段错误， core dump 文件

1. Segmentation fault 段错误：

操作系统向进程发的一个信号，告诉程序系统检测到一个非法内存访问。
为防止内存空间被破坏，操作系统提前终止该程序的执行。

SIGSEGV 无效内存段访问

信号：
通俗易懂说信号
https://blog.csdn.net/lqy971966/article/details/88938079

2. core dump 文件

2.1 core 定义

core文件是应用程序运行时的全部动态数据的一个快照，内核检测到应用程序接收到某些特殊信号时，会主动生成快照文件。

能够生成core文件的信号列表：

SIGQUIT / SIGILL / SIGTRAP / SIGABRT / SIGFPE /
 SIGSEGV / SIGBUS / SIGSYS / SIGXCPU / SIGXFSZ / SIGEMT

2.2 core内容：

	它其实就是程序的内存映像文件。
	它包含了程序时运行失败的那个时刻的全局变量的值。

2.3 gdb 调试 core 文件

2.3.1 gdb 调试 core

gdb a.out xxx.core或者 gdb /sbin/xxd abc.core

2.3.2 core文件的限制

当程序core dump时，可能会产生core文件，它能够很大程序帮助我们定位问题。但前提是系统没有限制core文件的产生。可以使用命令limit -c查看：
$ ulimit -c（用-a 更加全面）
0
如果结果是0，那么恭喜你，即便程序core dump了也不会有core文件留下。我们需要让core文件能够产生：
$ ulimit -c unlimied #表示不限制core文件大小
调试xxx进程的core文件：

gdb /sbin/xxx xxx.core

2.3.3 core 路径 core dump 限制

在做个项目的时候，发现没有core文件信息，但是unlimit 也打开了。
后来发现core文件的路径出了问题。

[root@glusterfs src]# vi /proc/sys/kernel/core_pattern
/tmp/core_%P_%p_%e_%s_%t

2.3.4 设置core文件的名称和文件路径

默认生成路径：输入可执行文件运行命令的同一路径下
默认生成名字：默认命名为core。新的core文件会覆盖旧的core文件

设置pid作为文件扩展名

1：添加pid作为扩展名，生成的core文件名称为core.pid
0：不添加pid作为扩展名，生成的core文件名称为core

修改 /proc/sys/kernel/core_uses_pid 文件内容为: 1
修改文件命令： echo “1” > /proc/sys/kernel/core_uses_pid

或者

sysctl -w kernel.core_uses_pid=1 kernel.core_uses_pid = 1

控制core文件保存位置和文件名格式

修改文件命令： echo “/tmp/core_%P_%p_%e_%s_%t” > /proc/sys/kernel/core_pattern

[root@glusterfs home]# cat /proc/sys/kernel/core_pattern
/tmp/core_%P_%p_%e_%s_%t
[root@glusterfs home]#

https://blog.csdn.net/u011417820/article/details/71435031
https://blog.csdn.net/shenhuan1104/article/details/76172698

参考：
通俗易懂说GDB调试（三）总结
https://blog.csdn.net/lqy971966/article/details/103118094