1. ulimit -S -c unlimited
2. 在apache主配置文件中增加一行：CoreDumpDirectory /var/apache_coredump #目录随意
3. chown修改/var/apache_coredump的权限为apache子进程可写
注意：不要开启太久，core文件太多。占用太多磁盘空间
调试
gdb /usr/bin/httpd core.123
apache的coredump
在实际工作当中，通过会出现某个应用造成死机问题。如何解决该问题。
方法一：最简单办法，看打印，通过反复调试，看是哪条语句造成造成了死机。这种方法效率低，而且有时不准确，比如一个系统中有多个进程，但A进程跑的B断点是，出现段错误，系统发出11号信号，造成B，C等进程接到11号信号反初始化而推出。实际当中可能不一定是A进程原因，因为此时B，C等进程也在并发执行，甚至A，B，c 三个进程都在访问某一共享资源（如共享内存等）。
方法二：让内核通过OOPS打出堆栈信息，PC指针和链接指针，进行pc指针分析或者堆栈回溯
内核默认是不支持OOPS打印，需要内核配置开关打开。通常内为了了优化性能，调试开关都不会打开，需要我们根据实际需要打开某些调试开关。
OOPS打出来可以看到：pc指针，LR链接库指针，CPU各个寄存器信息，堆栈信息。
简单情况：
从OOPS知道PC指针，如果该进程是没有调用库，可以直接将该进程反汇编 objdump -D -S xxx进程名>124.txt
再从123.txt找到该PC指针位置对于的C代码行，即可定位。
对于情况还可以使用addr2line PC指针 -e xxxx进程名 -f定位到某个C代码行
复杂情况：
如果一个进程包含很多库，甚至要调用底层驱动，定位起来就更加麻烦。
首先看pc指针地址确认是在死在内核态和用户态。还是KO模块，不同处理器架构不一样，可以看内核地址映射表 system.map
比如在MIPS系统中
用户程序地址空间： 0x00000000~0x7FFFFFFF；
内核地址空间： System.map文件中的_stext ~_etext，大概是0x80000000~0x80300000；
可加载模块地址空间：0xC0000000~0xC0800000
如果在用户空间：
首先通过cat /proc./pid/maps
查看 pc=xxxx 指针所在库，比如pc指针所在库为xxx.so ,而xx.so的地址访问为aaa~bbb
那么pc指针再 xxx.so库中偏移地址为xxx-aaa=ccc
对xxx.so 进行反汇编，objdump -D -S >345.txt
查找到ccc行就能找到对应行。
注意该进程以及改进程所在的库编译是必需加-g ,也不能strip，否则反汇编出来没有C代码的映射行
如果是在内核空间，可以通过堆栈回溯法进程回溯。该方法需要熟悉汇编，其次需要耐心，这里不详述。
堆栈回溯法出来OOPS
通过反汇编，然后堆栈回溯，找到出问题的函数，该方法需要熟悉汇编，其次需要耐心，这里不详述。
方法三：coredump分析法
对于死机问题，某些情况下OOPS打印出来的信息不足以分析。coreDump给了个详细的方法。
首先在内核当中打开coredup 开关，死机后就会产生一个core问题，事后可以通过 gdb调试方法来分析定位死机的位置。
转载请注明：爱开源 » 段错误等造成死机问题的分析，code分析