gdb 调试coredump文件过程

gdb 调试coredump文件过程：

第一步：首先需要一个进程的coredump文件，怎么搞出coredump文件呢？

1、 ps -fax|grep                 进程名称 找到进程的pid

2、gdb -p pid                     调试进程

3、gcore coredump名称        则生成core文件

https://www.cnblogs.com/wangjian8888/p/11978397.html 该链接有应用程序崩溃后生成core文件具体方法

第二步：找出coredump文件的应用程序

1、gdb -c corefile   使用gdb调试core文件

2、info auxv          索引31对应的是core文件的应用程序

第三部：gdb使用应用程序调试coredump文件

gdb  coredump应用程序  coredump文件     调试coredump文件 

 

通过以上三步就可以调试coredump文件了

通过以下命令调试coredump文件

info threads 显示所有线程

bt 显示线程堆栈信息

thread thread_num   切换线程

frame num  切换栈

info r 显示当前帧的寄存器信息 （每一帧的寄存器信息都是不相同的）

 

readelf应用coredump

readelf -h 读取coredump文件头

readelf -wl 读取应用程序debug_line

readelf -wf 读取应用程序fde和cie信息

 

 

gdb core 多线程

在linux环境下调试多线程，总觉得不像.NET那么方便。这几天就为找一个死锁的bug折腾好久，介绍一下用过的方法吧。

多线程如果dump，多为段错误，一般都涉及内存非法读写。可以这样处理，使用下面的命令打开系统开关，让其可以在死掉的时候生成core文件。   
ulimit -c unlimited
这样的话死掉的时候就可以在当前目录看到core.pid(pid为进程号)的文件。接着使用gdb:
gdb ./bin ./core.pid 
进去后，使用bt查看死掉时栈的情况，在使用frame命令。

还有就是里面某个线程停住，也没死，这种情况一般就是死锁或者涉及消息接受的超时问题(听人说的，没有遇到过)。遇到这种情况，可以使用：
gcore pid （调试进程的pid号）
手动生成core文件，在使用pstack(linux下好像不好使)查看堆栈的情况。如果都看不出来，就仔细查看代码，看看是不是在 if，return，break，continue这种语句操作是忘记解锁，还有嵌套锁的问题，都需要分析清楚了。

最后，说一句，静心看代码，捶胸顿足是没有用的。