引言
在《I/O的效率比较》中，我们在修改图1程序的BUF_SIZE为8388608时，运行程序出现崩溃，如下图1：
图1. 段错误
一般而言，导致程序段错误的原因如下：
内存访问出错，这类问题的典型代表就是数组越界。
非法内存访问，出现这类问题主要是程序试图访问内核段内存而产生的错误。
栈溢出， Linux默认给一个进程分配的栈空间大小为8M，因此你的数组开得过大的话会出现这种问题。
首先我们先看一下系统默认分配的资源:
$ ulimit -acore file size (blocks, -c) unlimiteddata seg size (kbytes, -d) unlimitedscheduling priority (-e) 0file size (blocks, -f) unlimitedpending signals (-i) 7884max locked memory (kbytes, -l) 64max memory size (kbytes, -m) unlimitedopen files (-n) 1024pipe size (512 bytes, -p) 8POSIX message queues (bytes, -q) 819200real-time priority (-r) 0stack size (kbytes, -s) 8192cpu time (seconds, -t) unlimitedmax user processes (-u) 7884virtual memory (kbytes, -v) unlimitedfile locks (-x) unlimited
可以看到默认分配的栈大小为8M。而刚好我们的代码里的栈大小调到了8M，因此出现了段错误。
那么有没有一种更直接明了的方法来识别和分析应用程序崩溃产生的bug呢？ 有，那就是通过程序崩溃后产生的core文件。
core文件
何为core文件.
core dump又叫内核转储, 在Unix系统中，核心映像（core image）就是“进程”执行当时的内存内容，当进程发生错误或收到“信号”而终止执行时，系统会将核心映像写入一个文件，以作为调试之用，这就是所谓的核心转储（core dump）。而core文件一般产生在进程的当前工作目录下。
所以core文件中只是程序的内存映像, 如果在编译时加入调试信息的话,那么还会有调试信息。
如何产生core文件
我们运行了a.out程序出现了“段错误”，但没有产生core文件。这是因为系统默认core文件的大小为0，所以没有创建。可以用ulimit命令查看和修改core文件的大小。
$ ulimit -c 0 <--------- c选项指定修改core文件的大小$ ulimit -c 1000 <--------指定了core文件大小为1000KB, 如果设置的大小小于core文件,则对core文件截取$ ulimit -c unlimited <---------------对core文件的大小不做限制
如果想让修改永久生效，则需要修改配置文件，如.bash_profile、/etc/profile或/etc/security/limits.conf
我们回到上面的代码演示，把core文件的大小调成不限制，再执行a.out，就可以在当前目录看到core文件了。
另外补充一些资料，说明一些情况也不会产生core文件。
进程是设置-用户-ID，而且当前用户并非程序文件的所有者；
进程是设置-组-ID，而且当前用户并非该程序文件的组所有者；
用户没有写当前工作目录的许可权；
文件太大。core文件的许可权(假定该文件在此之前并不存在)通常是用户读/写，组读和其他读。
为什么需要core文件
关于core产生的原因很多，比如过去一些Unix的版本不支持现代Linux上这种gdb直接附着到进程上进行调试的机制，需要先向进程发送终止信号，然后用工具阅读core文件。在Linux上，我们就可以使用kill向一个指定的进程发送信号或者使用gcore命令来使其主动出core并退出。
如果从浅层次的原因上来讲，出core意味着当前进程存在BUG，需要程序员修复。
从深层次的原因上讲，是当前进程触犯了某些OS层级的保护机制，逼迫OS向当前进程发送诸如SIGSEGV(即signal 11)之类的信号, 例如访问空指针或数组越界出core，实际上是触犯了OS的内存管理，访问了非当前进程的内存空间，OS需要通过出core来进行警示，这就好像一个人身体内存在病毒，免疫系统就会通过发热来警示，并导致人体发烧是一个道理（有意思的是，并不是每次数组越界都会出Core，这和OS的内存管理中虚拟页面分配大小和边界有关，即使不出core，也很有可能读到脏数据，引起后续程序行为紊乱，这是一种很难追查的BUG）。
core文件的名称和生成路径
默认情况下core的文件名叫"core"
/proc/sys/kernel/core_uses_pid可以控制core文件的文件名中是否添加pid作为扩展
文件内容为1,表示添加pid作为扩展名,生成的core文件格式为core.PID
为0则表示生成的core文件统一命名为core.
如何修改这个文件的内容？
$ echo "0" > /proc/sys/kernel/core_uses_pid
/proc/sys/kernel/core_pattern文件用于定制core的文件名，一般使用%配合不同的字符：
%p 出core进程的PID
%u 出core进程的UID
%s 造成core的signal号
%t 出core的时间，从1970-01-0100:00:00开始的秒数
%e 出core进程对应的可执行文件名
如何阅读core文件
产生了core文件之后，就是如何查看core文件，并确定问题所在，进行修复。为此，我们不妨先来看看core文件的格式，多了解一些core文件。
$ file core.4244 core.4244: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '/home/fireway/study/temp/a.out'
首先可以明确一点，core文件的格式ELF格式，通过使用readelf -h命令来查看更详细内容
$ readelf -h core.4244ELF 头： Magic： 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: CORE (Core 文件) Machine: Advanced Micro Devices X86-64 Version: 0x1 入口点地址： 0x0 程序头起点： 64 (bytes into file) Start of section headers: 0 (bytes into file) 标志： 0x0 本头的大小： 64 (字节) 程序头大小： 56 (字节) Number of program headers: 19 节头大小： 0 (字节) 节头数量： 0 字符串表索引节头： 0
了解了这些之后，我们来看看如何阅读core文件，并从中追查BUG。在Linux下，一般读取core的命令为：
$ gdb exec_file core_file
使用gdb，先从可执行文件中读取符号表信息，然后读取core文件。如果不与可执行文件搅合在一起可以吗？答案是不行，因为core文件中没有符号表信息，无法进行调试，可以使用如下命令来验证：
$ objdump -x core.4244 | tail 26 load16 00001000 00007ffff7ffe000 0000000000000000 0003f000 2**12 CONTENTS, ALLOC, LOAD 27 load17 00801000 00007fffff7fe000 0000000000000000 00040000 2**12 CONTENTS, ALLOC, LOAD 28 load18 00001000 ffffffffff600000 0000000000000000 00841000 2**12 CONTENTS, ALLOC, LOAD, READONLY, CODESYMBOL TABLE:no symbols <----------------- 表明当前的ELF格式文件中没有符号表信息
结合上面知识点，我们分别编译带-g的目标可执行mycat_debug和不带-g的目标可执行mycat，会发现mycat_debug的文件大小稍微大一些。使用readelf命令得出的结果比较报告，详细见附件-readelf报告.html
各自执行产生的core文件，再使用objdump命令得出的结果比较报告，详细见附件-objdump报告.html
最后我们各自使用gdb读取core文件，得出的结果比较报告，详细见附件-gdb_core报告.html
如果我们强制使用gdb mycat, 接着是带有调试信息的core文件，gdb会有什么提示呢？
Reading symbols from mycat...(no debugging symbols found)...done.warning: core file may not match specified executable file.[New LWP 2037]Core was generated by `./mycat_debug'.Program terminated with signal SIGSEGV, Segmentation fault.#0 0x0000000000400957 in main ()
接下来重点来看，为啥产生段错误？
使用gdb mycat_debug core.2037可见：
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1Copyright (C) 2014 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or later
可知程序段错误，代码是int n = 0;这一句，我们来看当前栈信息：
(gdb) info fStack level 0, frame at 0x7ffc4b59d670: rip = 0x400957 in main (io1.c:16); saved rip = 0x7fc5c0d5aec5 source language c. Arglist at 0x7ffc4b59d660, args: Locals at 0x7ffc4b59d660, Previous frame's sp is 0x7ffc4b59d670 Saved registers: rbp at 0x7ffc4b59d660, rip at 0x7ffc4b59d668
其中可见指令指针rip指向地址为0x400957, 我们用x命令来查看内存地址中的值。具体帮助查看gdb调试 - 查看内存一节
(gdb) x/5i 0x400957 或者x/5i $rip=> 0x400957
这条movl指令要把立即数0送到-0x800014(%rbp)这个地址去，其中rbp存储的是帧指针，其地址是 0x7ffc4b59d660，而-0x800014显然是个负数，十进制是8388628，且栈空间是由高地址向低地址延伸,见图2，那么n的栈地址就是-0x800014(%rbp)，也就是$rbp-8388628。当我们尝试访问此地址时
图2. 典型的存储空间安排
(gdb) x /b 0x7ffc4ad9d64c0x7ffc4ad9d64c: Cannot access memory at address 0x7ffc4ad9d64c
可以看到无法访问此内存地址，这是因为它已经超过了OS允许的范围。
ulimit命令参数及用法
功能说明：控制shell程序的资源。
补充说明：ulimit为shell内建指令，可用来控制shell执行程序的资源。
参 数：
-a 显示目前资源限制的设定。
-c 设定core文件的最大值，单位为KB。
-d <数据节区大小> 程序数据节区的最大值，单位为KB。
-f <文件大小> shell所能建立的最大文件，单位为区块。
-H 设定资源的硬性限制，也就是管理员所设下的限制。
-m <内存大小> 指定可使用内存的上限，单位为KB。
-n <文件数目> 指定同一时间最多可开启的文件数。
-p <缓冲区大小> 指定管道缓冲区的大小，单位512字节。
-s <堆叠大小> 指定堆叠的上限，单位为KB。
-S 设定资源的弹性限制。
-t 指定CPU使用时间的上限，单位为秒。
-u <程序数目> 用户最多可开启的程序数目。
-v <虚拟内存大小> 指定可使用的虚拟内存上限，单位为KB。
参考
Linux下运行C++程序出现“段错误(核心已转储)”的原因
ulimit命令参数及用法
Linux下core文件的演示分析
gdb分析core文件
Linux上Core Dump文件的形成和分析