核心转储（core dump），在汉语中有时戏称为吐核，是操作系统在进程收到某些信号而终止运行时，将此时进程地址空间的内容以及有关进程状态的其他信息写出的一个磁盘文件。这种信息往往用于调试。

在UNIX系统中，常将“主内存”(main memory) 称为核心(core)，因为在使用半导体作为内存材料之前，便是使用核心(core)。而核心映像(core image) 就是 “进程”(process)执行当时的内存内容。当进程发生错误或收到“信号”(signal) 而终止执行时，系统会将核心映像写入一个文件，以作为调试之用，这就是所谓的核心转储(core dump)。

有时程序并未经过彻底测试，这使得它在执行的时候一不小心就会找到破坏。这可能会导致核心转储(core dump)。幸好，现行的UNIX系统极少会面临这样的问题。即使遇到，程序员可以通过核心映像(core image)调试程序来找到错误原因。

核心文件一词来源于磁芯内存（core memory），1950-1970年代的主要的随机存取存储介质。

核心文件通常在系统收到特定的信号时由操作系统生成。信号可以由程序执行过程中的异常触发，也可以由外部程序发送。动作的结果一般是生成一个某个进程的内存转储的文件，文件包含了此进程当前的运行堆栈信息。有时程序并未经过彻底测试，这使得它在执行的时候一不小心就会找到破坏。这可能会导致核心转储（core dump）。UNIX系统极少会面临这样的问题。即使遇到，程序员可以通过核心映像调试程序来找到错误原因。

程序自身产生的coredump文件一般可以用来分析程序运行到哪里出错了。

Linux平台常用的coredump文件分析工具是gdb；Solaris平台用pstack和pflags；Windows平台用userdump和windbg。

外部程序触发的dump一般用来分析进程的运行情况，比如分析内存使用/线程状态等。

Solaris的常用内存分析工具umem就是需要先通过gcore pid得到coredump的文件然后继续分析内存情况。

C/C++程序员遇到的比较常见的一个问题， 就是自己编写的代码， 在运行过程中出现了意想不到的核心转储。程序发生核心转储的原因是多方面的， 不同的核心转储问题有着不同的解决办法， 同时， 不同的核心转储问题解决的难易程度也存在很大的区别， 有些在短短几秒钟内就可以定位问题， 但是也有一些可能需要花费数天时间才能解决， 这种问题是对软件开发人员的极大的挑战。笔者从事C/C++语言的软件开发工作多年， 前后解决了许多此类问题， 久而久之积累了一定的经验， 现把常见程序核心转储总结一下， 供软件开发人员共飨。

1.无效指针引起的程序核心转储这种情况是一种最常见的核心转储， 大致可以有4 种原因导致程序出现异常：

（1） 对空指针进行了操作。

（2） 对一个未初始化的指针进行了操作。

（3） 对一个已经调用delete 释放了内存的指针再次调用了

delete 去重复释放（谁让你不在第一次delete 后， 将指针赋值为NULL 呢）。

（4） 多线程访问全局变量， 导致内存值异常而程序核心转储。

此类问题通常是代码编写时的疏漏造成的， 属于低级故障， 也比较容易解决， 用调试工具调试一下产生的core 文件，对照代码定位问题出现的原因，10 分钟就可以搞定。

2. 指针越界引起的程序核心转储

这种情况属于一种隐藏比较深的核心转储， 比较难以解决。遇到这种问题时， 用调试工具调试这个core 文件， 尽管也能定位到代码行， 但是从对应行的代码看， 可能这行代码本身并没有什么问题， 它只是一个“被陷害者”。这种核心转储很难发现， 解决起来难度较大。根据笔者的经验， 这种核心转储很可能是其他代码处理过程中的内存越界造成的， 通常由以下两个因素引起。第一个因素：核心转储所在的代码行是一个很简单的操作， 例如赋值语句， “这怎么可能出错呢？” 注释掉该语句运行程序， 核心转储又发生在下一行代码上。此时，相应代码行的操作很可能是对某个全局变量B 的操作， 在这种情况下， 需要将视线转移到该全局变量的定义行代码， 仔细看看该全局变量前后附近定义的变量A，C 因为操作系统不同， 变量位置也不同，有的需要关注B 变量前面定义的变量A， 有的需要关注B 变量后面定义的变量C， 仔细搜索代码， 看看对A，C 变量的处理有没有可能导致内存越界的地方， 很可能就是因为对A，C 操作出现内存越界导致B 变量的操作受到伤害， B 够背运吧。

第二因素： 核心转储的位置内存变量的值莫名其妙， 出现

了异常的值。此时， 需要仔细分析代码和处理流程了。首先排查本函数的代码处理是否有问题， 重点关注memcpy、strstr、sprintf、strcpy 和strcat 等极易出现问题的代码行， 如果确认本函数处理没有问题， 那么就需要根据流程来仔细走查代码， 在这种情况下， 最需要的是耐心和信心。对于这类问题， 肯定是代码走到了某个特殊的逻辑里面， 代码处理缺少必要的保护而引起的， 出现一次， 没有足够的日志记录流程， 很难分析， 从core 文件的内存变量的值也无法定位问题原因。但是， 如果再次出现， 那么就具有比较大的参考价值了， 前后两次的core文件内存变量必然存在某种共性， 需要根据这个特征来分析并复现故障了。笔者曾经遇到对一个未初始化的缓冲区A 做字符串操作strstr （此时它并不会核心转储）， 但是当流程走了很多之后走到另一个对变量B 的操作时， 出现了核心转储； 更有甚者， 模块内一个链表算法出现了失误， 导致指针越界。

3. 操作系统相关的特殊性造成的程序核心转储

初学者对于这种情况， 必然让人备感莫名其妙的， “这么简单而又规范的代码， 怎么会出这种问题？” 这种问题与2 的区别在于， 问题很容易复现， 可能程序一运行就核心转储。尽管对这种核心转储很不解， 但应该相信： 越容易出现的问题，越容易解决。就像作为程序员编译一个程序， 一下子出现了几百个编译错误， 根本不用担心， 很可能就是某一行代码多了几个字符， 当把这些代码删去再编译， 几百个编译错误全都消失了。

常遇到的此类问题有两种情况。

第一种情况： 字节对齐方式引起的程序核心转储。可能有两个原因： 其一， 合作伙伴的模块与自身模块所定义的结构体的字节对齐方式不同， 而导致程序出现核心转储； 其二， 在代码中， 把引用到的别的模块的头文件包含到自身文件中的字节对齐方式语法声明的中间了， 结果导致字节对齐方式出现了变化。此类问题不是很常见， 不过一旦出现， 往往让人觉得很蹊跷。其实此类问题从源头上解决应该还是比较简单的， 关键在于一个良好的习惯， 如果在定义接口消息的时候， 多花点时间规整结构体的字段定义， 把它往4 字节的倍数上靠即可， 应该没必要处处节省那么点内存。第二种情况： 程序核心转储情况， 是与程序编译时的链接参数不正确而导致程序运行在反复操作大内存时出现核心转储。经过反复的代码删减、编译和运行的试验， 最终发现问题规律， 于是怀疑和操作系统或者编译有关， 最终解决了这个问题。程序发生核心转储的根本原因还是程序员自己进行程序设计时的编码失误造成的， 这种代码失误绝大多数都是因为没有严格遵守相应的代码编写规范， 所以， 要从根本上杜绝或者减少程序核心转储现象的发生， 还是要从严格遵守代码编写规范来做起。