做 Linux 相关的开发工作，core 文件是一定会接触到的。Linux 小白对 core 文件可能会一筹莫展，这里就系统的讲解一下 core 文件的生成，以及怎么利用 core 文件分析问题。
注：本文所用的环境是嵌入式 Linux，相对于 PC 会有一些精简。
1. 基本原理
Core dump 文件是系统收到特定信号时由操作系统生成的。信号可以是由程序运行过程的异常触发，或者由外部进程发送。导致的结果一般是某个进程生成 core dump 文件，文件包含了此进程当前的运行堆栈信息，方便开发人员用来分析问题。
2. 生成 core 文件
用 ulimit -a 命令查看系统是否已设置可以生成 core 文件。如果 core file size 项是 0，则说明当前系统已经关闭 core 文件生成。
用 *ulimit -c * 命令开启生成 core 文件功能。
ulimit -c unlimited # 开启 core 文件生成，且不限 core 文件大小
ulimit -c 100 # 开启 core 文件生成，且限 core 文件大小为 100KB
那生成的 core 文件是放置在哪里呢？
这个同样可以设置，命令如下：
echo /data/core-%p > /proc/sys/kernel/core_pattern命令中带 *% * 的是参数，可以指定文件名格式，在文件名加上我们想要的信息，可以帮助我们快速定位问题方向；同时也可以区分不同进程的 core 文件。可以使用的参数如下表格：
参数 | 说明 |
%e | 所 dump 的文件名 |
%g | 所 dump 的进程的实际组 ID |
%h | 主机名 |
%p | 所 dump 的进程PID |
%s | 导致本次 coredump 的信号 |
%t | 转储时刻 (由1970年1月1日起计的秒数) |
%u | 所 dump 进程的实际用户ID |
如使用以下命令设定：
echo /data/core-%p-%s-%e > /proc/sys/kernel/core_pattern生成的 core 文件如下：
从 core 文件名就可以看出进程 ID，进程退出的原因，以及出现问题的函数等信息。这是一个 demo 进程，只有一个 main.c 文件，main 函数里面给空指针赋值，所以系统给进程发送 SIGSEGV (11) 信号，使进程退出。
3. 分析 core 文件
Linux 平台常用的 core dump 文件分析工具是 gdb。
我们将以上的 demo 程序稍微改一下，增加一层函数调用，然后我们再分析 core 文件，看能不能定位到出问题的函数。
经过上面一顿操作之后，生成 core 文件，然后我们再用 gdb 工具来分析。
我所有的 gdb 工具是用交叉工具链编译好，可以直接在嵌入式 linux 上运行的，所以生成 core 文件后，可以直接在运行环境上分析，而不需要拷贝到 PC 上。
用 gdb 分析 core 文件，就可以定位到具体的问题点。
这里只是简单提到 gdb 的使用，我将在另外一篇详细讲一下 gdb 的使用。
