Coredump故障分析

core dump背景

由于一些程序运行异常时间不定，可能几天可能几个月。所以人为去调试找到错误的信息时间太久。所以可以利用coredump来监视，程序异常时会生成错误并存在core文件，通过工具分析这个文件，就可以定位错误

Coredump对付那种错误

产生错误的原因有许多，但一般是段错误segment fault，原因总结如下：
1. 数组访问越界
2. 访问空指针，非法指针
3. 栈溢出
4. 修改只读内存
5. 搜索字符串，例：依靠字符串结束符来判断字符串是否结束，但是字符串没有正常的使用结束符。
6. 使用strcpy，strcat，sprintf，strcmp等字符串操作字符，将目标字符串写爆炸。应该使用strncpy，strlcpy，strncat，等对宽度限制的函数防止读写越界
7. 随意使用指针转换。一个指向一段内存的指针，除非确定这段内存原先就分配为某种结构或类型，或者这种结构或类型的数组，否则不要将它转换为这种结构或类型的指针，而应该将这段内存拷贝到一个这种结构或类型中，再访问这个结构或类型。这是因为如果这段内存的开始地址不是按照这种结构或类型对齐的，那么访问它时就很容易因为bus error而core dump。
8. 多线程读写数据未加锁保护

Coredump的使用

Linux系统中，默认是关闭coredump
ulimit -c unlimited ：打开coredump
ulimit -c 0 ：关闭coredump
1. 打开coredump后，写一段犯上述一种错误的程序，编译时候要加上 -g选项，这样发生错误时候生成的core信息会详细。然后执行编译程序。
2. 生成core例如为 core.12525.
3. 用gdb对信息进行调试 执行 gdb ./test core.12525 ,输出信息会提示在何处出错（gdb + 编译后可执行程序名 + core文件名 ）

Coredump文件的储存位置

core文件默认的储存位置与对应的可执行程序在同一目录，文件名是core
注意：有好多程序崩溃却找不到core文件，一般是在同一路径，但是如果程序中调用了chdir函数，则有可能改变当前工作目录。这时就在chdir的指定路径下了。（当然程序崩溃了不一定都产生core文件）
通过下面的命令可以更改coredump文件的存储位置，若你希望把core文件生成到/data/coredump/core目录下：
echo “/data/coredump/core”> /proc/sys/kernel/core_pattern

注意，这里当前用户必须具有对/proc/sys/kernel/core_pattern的写权限。

缺省情况下，内核在coredump时所产生的core文件放在与该程序相同的目录中，并且文件名固定为core。很显然，如果有多个程序产生core文件，或者同一个程序多次崩溃，就会重复覆盖同一个core文件，因此我们有必要对不同程序生成的core文件进行分别命名。

我们通过修改kernel的参数，可以指定内核所生成的coredump文件的文件名。例如，使用下面的命令使kernel生成名字为core.filename.pid格式的core dump文件：
echo “/data/coredump/core.%e.%p” >/proc/sys/kernel/core_pattern
这样配置后，产生的core文件中将带有崩溃的程序名、以及它的进程ID。上面的%e和%p会被替换成程序文件名以及进程ID。
如果在上述文件名中包含目录分隔符“/”，那么所生成的core文件将会被放到指定的目录中。 需要说明的是，在内核中还有一个与coredump相关的设置，就是/proc/sys/kernel/core_uses_pid。如果这个文件的内容被配置成1，那么即使core_pattern中没有设置%p，最后生成的core dump文件名仍会加上进程ID。

修改名之后如何判断文件是不是core文件

执行 file + 文件名