浏览关于coredump的文章时，下面两篇文章说的清晰易懂，转发下：
https://blog.csdn.net/asdfghjkl0606/article/details/52841678
https://blog.csdn.net/stpeace/article/details/119699330
http://wjhsh.net/zhchoutai-p-6717780.html
第一篇：简单介绍coredump基本概念和操作
引言：程序在Linux系统中运行时出错的时间并不能预测，也许在三分钟之内程序就崩溃了，也许运行一个月之后才发生错误。
如果前一节课学到的GDB调试，显然调试上十天半个月是不可能的。这里我们用core dump来解决。
一、Core Dump：信息转存、核心转存。
core dump是一个过程，即Linux会把程序运行过程中发生异常的内存内容转存到core文件。
core dump主要解决段错误（Segment fault）。
二、发生段错误的基本原因有：
1、数组访问越界；
2、对空指针操作；
3、栈溢出；
4、修改只读内存的内容。
三、启用/关闭 Core Dump：
打开：ulimit -c unlimited
关闭：ulimit -c 0
（在Linux系统中默认关闭该功能）
四、Core文件分析：
在发生core dump之后会在该程序所在路径下生成一个core文件。
注意：在编译程序时需要用-g来加入调试信息，否则将让错误逃之夭夭。
> gdb ./test core.13140
#include <stdio.h>
#include <stdlib.h>
void main()
{
int *ptr = NULL;
*ptr = 3;
}
第二篇：告诉你一般定位这类问题的思路
core的最原始含义是磁芯，是一种存储设备，dump的意思是倒出，那么core dump的含义就是：当进程发生异常时，会把当时的内存信息倾倒出来，形成core文件。
每个做linux C++开发的人，必然会遇到过core dump问题。在C++相关的面试中，core dump的调试，几乎是一个必考的考点，旨在检验应聘者的实战调试经验。
我知道的一个真实案例是：面试官让应聘者现场写出一个core dump程序，结果应聘者很懵圈，不知道怎么写。这说明，应聘者没有相关的调试经历，何谈通过面试？
接下来，我们以一个简单的core dump程序为例，来说说调试core dump的六种经验和方法，希望能对大家的开发实战有所帮助，顺便地，横扫那些简单的面试题。
方法一: 代码review
代码review，是一种比较原始的笨方法。对于简单的代码而言，还可以进行review, 但是，一旦代码达到数万行，出现core dump后，便无从看起。所以，这种方法很鸡肋，几乎没什么用。
方法二: 打印log夹逼
打印log来夹逼，也是一种很简单的方法，在很多场景下，非常奏效。许多大学生和职场新手，容易出现core dump问题，那么, 我建议直接用log夹逼。有点类似二分查找，且看具体的姿势：其实很多老鸟也是这么做的。
方法三: dmesg + addr2line
有时候，如果core dump的开关没有打开，无法生成core文件，那怎么办呢？也是有办法的！用dmesg和addr2line吧。关于这两个命令的介绍，直接man一下即可。且看具体调试：
以前确实没用过dmesg。按照上面的操作没出现相关的段错误。
方法四: strace + addr2line
接下来，我们介绍一个重要的linux命令，即strace, 直接man一下就知道，它是用查看系统调用的，我们不过多赘述。来看具体的调试过程：
后面跟的那串数字是什么含义？地址？ 实际操作的时候可以看到段错误。但是addr2line 后面那个a.out没有对应的。
方法五: valgrind
之前，在调试内存泄漏时，介绍过valgrind，其实valgrind能查其他更多内存问题，非常强大。下面，我们来看看valgrind查core dump问题，如下：
valgrind 是 Linux 业内流行且十分强劲的内存泄漏查验专用工具。在其官方网站详细介绍中，运行内存查验（memcheck）仅仅其在其中一个作用。因为仅用过其内存泄漏的查验，也不扩展共享 valgrind 别的作用了。
没有使用过。暂不描述。
方法六: gdb
gdb调试，是本文的重头戏，也几乎是笔试面试的必考内容。话不多说，直接来看姿势。使用gdb a.out core(不会重新拉取a.out进程)或者gdb a.out(会重新拉起a.out进程)都可以，如下：
第三篇：linux程序调试命令addr2line之入门简单介绍
addr2line有什么作用呢？ 可别小瞧它， 它能够定位到代码出错的位置。
以下， 我们来看看这个简单的代码：
#include <stdio.h>
int main()
{
int *p = NULL;
*p = 0;
printf("bad");
return 0;
}
这个程序非常小， 我们能够一眼就看出程序在执行期出错。 可是， 假设是大程序， 在执行期出错。 我们该怎样定位呢？ 那就必须依赖于工具。 而不是你我的肉眼。
我们以上述小程序为例， 进行例如以下操作：
[taoge@localhost learn_c]$ gcc -o taogeSeg -g taogeSeg.c
[taoge@localhost learn_c]$ ./taogeSeg
Segmentation fault (core dumped)
[taoge@localhost learn_c]$ dmesg | grep taogeSeg
taogeSeg[4941]: segfault at 0 ip 080483c9 sp bfb92410 error 6 in taogeSeg[8048000+1000]
[taoge@localhost learn_c]$ addr2line -e taogeSeg 080483c9
/home/taoge/Desktop/learn_c/taogeSeg.c:6
[taoge@localhost learn_c]$ cat -n taogeSeg.c
1 #include <stdio.h>
2
3 int main()
4 {
5 int *p = NULL;
6 *p = 0;
7
8 printf("bad
");
9 return 0;
10 }
[taoge@localhost learn_c]$
但是我在实际操作过程中，发现dmesg没有任何相关的linux core信息出来。不清楚是不是linux版本问题。
我来解释一下：
1. gcc -o taogeSeg -g taogeSeg.c ：生成带有调试信息的可运行文件taogeSeg
2. dmesg | grep taogeSeg ：获得运行taogeSeg后的出错信息， 你能够将结果理解为日志， 当中的080483c9是一个地址， 正是这个地址出错了
3. addr2line -e taogeSeg 080483c9 ：将出错地址转换成源码相应的行， 结果为6， 也就是说源码第6行有问题。 一看， 果然是，万恶的*p=0;被揪出来了。
当然。 针对这个样例， 会gdb调试的朋友肯定也能调试出来，并且也确实能找到代码出错的地址和源码行， 从这个意义上来讲。 gdb内部也携带了类addr2line的功能。这是不是说gdb就能够替代addr2line呢？ 不是的。
假设某bug低概率发生。 如今仅仅有一份crash log, 那就要用addr2line了， 由于你用gdb时。 该bug不一定发生啊。
实际上， 在非常多linux大型软件开发中， 常常出现段错误， 造成进程挂掉， 系统崩溃等问题， 此时， 用addr2line是比較好的方法。
在后面的博文中， 我们会继续了解与addr2line有关的调试方法， 毕竟， 代码调试太重要了。事实上呢， 假设不熟悉addr2line的使用， 或者干脆没有听说过这个命令， 那最好不要说自己搞linux开发。 免得被人歧视啊。
OK, 本文仅仅是一个引子， 能在实战中熟练使用addr2line才见真功夫。
如能熟练掌握addr2line的使用。 以后听到什么段错误， 系统崩溃。 就没那么毛骨悚然了。
标签：Core,taogeSeg,Dump,dump,core,gdb,调试,addr2line,转存 From： https://www.cnblogs.com/beilou310/p/16963662.html