linux查程序崩溃方法
dmesg 查看程序崩溃原因分析方法之一
在linux下写c/c 程序的程序员，时常与core dump相见。在内存越界访问，收到不能处理的信号，除零等错误出现时，我们精心或不精心写就的程序就直接一命呜呼了，core dump是linux仁慈地留下的程序的尸体，帮助程序员们解决了一个又一个问题。
有时配置不给力，linux直接毁尸灭迹，没有了core文件；又有时，刚好磁盘空间不足，core文件写不下了。没有core文件的时候，如何知道程序在什么地方出错了呢？addr2line就在这时派上用场。
这是一个示例程序，func函数返回参数a除以参数b的结果。这里使用0作为除数，结果就是程序因为除以0导致错误，直接中断了。
#include int func(int a, int b) { return a / b; } int main() { int x = 10; int y = 0; printf("%d / %d = %d\n", x, y, func(x, y)); return 0; }
使用
$ gcc -o test1 -g test1.c
编译程序，test1.c是程序文件名。执行程序，结果程序异常中断。查看系统dmesg信息，发现系统日志的错误信息：
[54106.016179] test1[8352] trap divide error ip:400506 sp:7fff2add87e0 error:0 in test1[400000 1000]
这条信息里的ip字段后面的数字就是test1程序出错时所程序执行的位置。使用addr2line就可以将400506转换成出错程序的位置：
$ addr2line -e test1 400506 /home/hanfoo/code/test/addr2line/test1.c:5
这里的test1.c:5指的就是test1.c的第5行
return a / b;
也正是这里出现的错误。addr2line帮助我们解决了问题。
addr2line如何找到的这一行呢。在可执行程序中都包含有调试信息， 其中很重要的一份数据就是程序源程序的行号和编译后的机器代码之间的对应关系line number table。dwarf格式的line number table是一种高度压缩的数据，存储的是表格前
后两行的差值，在解析调试信息时，需要按照规则在内存里重建line number table才能使用。
line number table存储在可执行程序的.debug_line域，使用命令
$ readelf -w test1
可以输出dwarf的调试信息，其中有两行
spec