关于Segmentation fault (core dumped)
关于Segmentation fault (core dumped)几个简单问题的整理
有的程序可以通过编译，但在运行时会出现Segment fault(段错误)。这通常都是指针错误引起的。但这不像编译错误一样会提示到文件一行，而是没有任何信息。一种办法是用gdb的step, 一步一步寻找。但要step一个上万行的代码让人难以想象。 我们还有更好的办法，这就是core file。
如果想让系统在信号中断造成的错误时产生core文件, 我们需要在shell中按如下设置:
#设置core大小为无限ulimit -c unlimited
#设置文件大小为无限ulimit unlimited
发生core dump之后，用gdb进行查看core文件的内容, 以定位文件中引发core dump的行：
gdb [exec file] [core file]
如: gdb ./test test.core 在进入gdb后，用bt命令查看backtrace以检查发生程序运行到哪里，来定位core dump的文件->行。
另外需要注意的是，如果你的机器上跑很多的应用，你生成的core又不知道是哪个应用产生的，你可以通过下列命令进行查看：file core
几个问题：
1. 什么是Core：
在使用半导体作为内存的材料前，人类是利用线圈当作内存的材料（发明者为王安），线圈就叫作 core ，用线圈做的内存就叫作 core memory。如今，半导体工业澎勃发展，已经没有人用 core memory 了，不过，在许多情况下，人们还是把记忆体叫作 core 。
2. 什么是Core Dump：
我们在开发（或使用）一个程序时，最怕的就是程序莫明其妙地当掉。虽然系统没事，但我们下次仍可能遇到相同的问题。于是这时操作系统就会把程序当掉时的内存内容 dump 出来（现在通常是写在一个叫 core 的 file 里面），让我们或是 debugger 做为参考。这个动作就叫作 core dump。
3. Core Dump时会生成何种文件：
Core Dump时，会生成诸如 core.进程号的文件。
4. 为何有时程序Down了，却没生成 Core文件。
Linux下，有一些设置，标明了resources available to the shell and to processes。可以使用
#ulimit -a 来看这些设置。 (ulimit是bash built-in Command)
从这里可以看出，如果 -c是显示：core file size。如果这个值为0，则无法生成core文件。所以可以使用：#ulimit -c 1024或者 #ulimit -c unlimited来使能 core文件。如果程序出错时生成Core 文件，则会显示Segmentation fault (core dumped) 。
5. Core Dump的核心转储文件目录和命名规则：
/proc/sys/kernel /core_uses_pid可以控制产生的core文件的文件名中是否添加pid作为扩展，如果添加则文件内容为1，否则为0
可通过以下命令修改此文件：
echo"1" > /proc/sys/kernel/core_uses_pid
6. 如何使用Core文件：
在Linux下，使用：
#gdb -c core.pid program_name
就可以进入gdb模式。
输入where，就可以指出是在哪一行被Down掉，哪个function内，由谁调用等等。
(gdb) where
或者输入 bt。
(gdb) bt
7. 如何让一个正常的程序down:
#kill -s SIGSEGV pid
8. 察看Core文件输出在何处：
存放Coredump的目录即进程的当前目录，一般就是当初发出命令启动该进程时所在的目录。但如果是通过脚本启动，则脚本可能会修改当前目录，这时进程真正的当前目录就会与当初执行脚本所在目录不同。这时可以查看”/proc/<进程pid>/cwd“符号链接的目标来确定进程真正的当前目录地址。通过系统服务启动的进程也可通过这一方法查看。
proc/sys/kernel /core_pattern可以控制core文件保存位置和文件名格式。
可通过以下命令修改此文件：
echo"/corefile/core-%e-%p-%t" >core_pattern
可以将core文件统一生成到/corefile目录下，产生的文件名为core-命令名-pid-时间戳
以下是参数列表:
%p - insert pid into filename 添加pid
%u - insert current uid into filename 添加当前uid
%g - insert current gid into filename 添加当前gid
%s - insert signal that caused the coredump into the filename 添加导致产生core的信号
%t - insert UNIX time that the coredump occurred into filename 添加core文件生成时的unix时间
%h - insert hostname where the coredump happened into filename 添加主机名
%e - insert coredumping executable name into filename 添加命令名
在Linux下要保证程序崩溃时生成 Coredump要注意这些问题：
一、要保证存放Coredump的目录存在且进程对该目录有写权限。存放Coredump 的目录即进程的当前目录，一般就是当初发出命令启动该进程时所在的目录。但如果是通过脚本启动，则脚本可能会修改当前目录，这时进程真正的当前目录就会与当初执行脚本所在目录不同。这时可以查看”/proc/进程pid>/cwd“符号链接的目标来确定进程真正的当前目录地址。通过系统服务启动的进程也可通过这一方法查看。
二、若程序调用了seteuid()/setegid()改变了进程的有效用户或组，则在默认情况下系统不会为这些进程生成Coredump。很多服务程序都会调用seteuid()，如MySQL，不论你用什么用户运行 mysqld_safe启动MySQL，mysqld进行的有效用户始终是msyql用户。如果你当初是以用户A运行了某个程序，但在ps里看到的这个程序的用户却是B的话，那么这些进程就是调用了seteuid了。为了能够让这些进程生成core dump，需要将/proc/sys/fs
/suid_dumpable 文件的内容改为1（一般默认是0）。
三、这个一般都知道，就是要设置足够大的Core文件大小限制了。程序崩溃时生成的 Core文件大小即为程序运行时占用的内存大小。但程序崩溃时的行为不可按平常时的行为来估计，比如缓冲区溢出等错误可能导致堆栈被破坏，因此经常会出现某个变量的值被修改成乱七八糟的，然后程序用这个大小去申请内存就可能导致程序比平常时多占用很多内存。因此无论程序正常运行时占用的内存多么少，要保证生成Core文件还是将大小限制设为unlimited为好。
四、异常退出就一定会生成core吗？难道没有不生成core的异常退出？
如果不是正常退出的那就是有信号引起的程序退出，有些信号确实能引起程序退出但不生成core。
SIGHUP终止进程终端线路挂断
SIGINT终止进程中断进程
SIGQUIT建立CORE文件终止进程，并且生成core文件
SIGILL 建立CORE文件非法指令
SIGTRAP建立CORE文件跟踪自陷
SIGBUS建立CORE文件总线错误
SIGSEGV建立CORE文件段非法错误
SIGFPE建立CORE文件浮点异常
SIGIOT建立CORE文件执行I/O自陷
SIGKILL终止进程杀死进程
SIGPIPE终止进程向一个没有读进程的管道写数据
SIGALARM终止进程计时器到时
SIGTERM终止进程软件终止信号
SIGSTOP停止进程非终端来的停止信号
SIGTSTP停止进程终端来的停止信号
SIGCONT忽略信号继续执行一个停止的进程
SIGURG忽略信号I/O紧急信号
SIGIO忽略信号描述符上可以进行I/O
SIGCHLD忽略信号当子进程停止或退出时通知父进程
SIGTTOU停止进程后台进程写终端
SIGTTIN停止进程后台进程读终端
SIGXGPU终止进程CPU时限超时
SIGXFSZ终止进程文件长度过长
SIGWINCH忽略信号窗口大小发生变化
SIGPROF终止进程统计分布图用计时器到时
SIGUSR1终止进程用户定义信号1
SIGUSR2终止进程用户定义信号2
SIGVTALRM终止进程虚拟计时器到
把可能的信号都设置上句柄，看是那种情况。
下面主要来介绍下问题的解决与查找，aix下通常使用dbx就行调试跟踪，在linux下一般都使用gdb进行调试，那今天我就以linux环境作为介绍，来查找正在的core dumped的原因。需要说明的是，你在编译程序的时候要加调试选项 -g。
语法：gdb 应用 core
这样出来的会有一堆东西，你先别管，在输入行中输入where.
这就回显示就是core是发生在什么地方，首先你看的顺序从列表的下方往上看，因为这是一个“栈”的顺序。
你可以马上可以看到是什么原因导致的，有兴趣的可以试试看。
另外需要注意的是，如果你的机器上跑很多的应用，你生成的core又不知道是哪个应用产生的，你可以通过下列命令进行查看：
file core