gdb常用的调试方法

1. 安装gdb

     yum install gdb

2. 打印线程的堆栈

     1，ps -afx   //查看进程id

     2，attach 正在运行的进程

           gdb debugme pid

     3，set logging file /tmp/test.txt   //设置操作gdb的日志输出文件

          set logging on  //打开日志输出

          thread apply all bt  //输出所有的线程堆栈 

gdb attach到 httpd后的例子：

(gdb) set logging file /tmp/test.txt
(gdb) set logging on
Copying output to /tmp/test.txt.
(gdb) thread apply all bt

Thread 2 (Thread 0x41ec5940 (LWP 7312)):
#0  0x00002b6370d241c0 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00002aaab3bbf229 in ?? () from /usr/lib64/libnspr4.so
#2  0x00002aaab3bbfe69 in PR_WaitCondVar () from /usr/lib64/libnspr4.so
#3  0x00002aaab3bc51bc in PR_Sleep () from /usr/lib64/libnspr4.so
#4  0x00002aaab302750e in ?? () from /usr/lib64/libssl3.so
#5  0x00002aaab3bc55cd in ?? () from /usr/lib64/libnspr4.so
#6  0x00002b6370d1f77d in start_thread (arg=<value optimized out>) at pthread_create.c:301
#7  0x00002b637120d9ad in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x2b63731b4360 (LWP 4718)):
#0  0x00002b6371206b42 in select () from /lib64/libc.so.6
#1  0x00002b6370b10d25 in apr_sleep () from /usr/lib64/libapr-1.so.0
#2  0x00002b636f242315 in ap_wait_or_timeout ()
#3  0x00002b636f24b79e in ap_mpm_run ()
#4  0x00002b636f225fd8 in main ()

现在可以在/tmp/test.txt自由查看堆栈信息了

3，根据dump里的地址，查看对应的代码函数

       info symbol 0x12ffeedd

       list 0x11ffeedd

4，非交互模式 下，打印core文件 堆栈

          gdb -q --batch --ex "set height 0" -ex "thread apply all bt full" [可执行文件] [core文件]

          -q: 不打印gdb的版权消息

          --batch: 执行批处理，不进入交互模式

           --ex: 执行gdb 命令

           "set height 0": 不对输出进行分页

           "thread apply all bt full": 打印所有线程堆栈

pmap，来输出进程内存的状况，可以用来分析线程堆栈

 gdb 里这个命令就叫dump，这里仅给出一种简单的用法，其他的可以在gdb里 help。

dump binary memory file start_addr end_addr

前面就写dump binary memory，后面接文件名，接着是起始地址，然后是尾地址。dump出来的数据怎么用就随君了。

　什么是Core Dump?

　　Core的意思是内存, Dump的意思是扔出来, 堆出来.开发和使用Unix程序时, 有时程序莫名其妙的down了, 却没有任何的提示(有时候会提示core dumped). 这时候可以查看一下有没有形如core.进程号的文件生成运行过程中发生异常, 程序异常退出时, 由操作系统把程序当前的内存状况存储在一个core文件中, 叫core dump.这个文件便是操作系统把程序down掉时的内存内容扔出来生成的, 它可以做为调试程序的参考.

　　Core Dump又叫核心转储, 当程序没有core文件生成怎么办呢?

　　有时候程序down了, 但是core文件却没有生成，core文件的生成跟你当前系统的环境设置有关系, 可以用下面的语句设置一下, 然后再运行程序便会生成core文件.

　　ulimit -c unlimited

　　core文件生成的位置一般于运行程序的路径相同, 文件名一般为core.进程号，在我的ubuntu12.04lts下生产的文件名为core。

　　介绍了core dump之后，来看看如何在多线程调试中使用core dump。

　　使用 kill 命令产生 core dump文件：

　　kill -11 pid

　　这不还是杀掉进程嘛？没错，但是你用信号11杀掉它，会让进程产生一个 Segmentation Fault，从而（如果你没禁用 core dump 的话），导致一个 core dump。随后你得到一个 core 文件，里面包含了死锁的时候，进程的内存镜像，也就包括了正在纠结缠绵，生离死别从而产生死锁的那两个，没准是几个，线程们的，栈。

　　现在知道该怎么办了吧？用 gdb 打开这个 core 文件，然后

　　thread apply all bt

　编译代码

　　$> g++ -Wall -std=c++11 dead_lock_demo.cpp -o dead_lock_demo -g -pthread

　　运行程序，发现程序打印出“about to dead_lock” 就不动了，现在我们使用gdb来调试。注意gdb的版本要高于7.0，之前使用过gdb6.3调试多线程是不行的。

　　在这之前需要先产生core dump文件：

　　$> ps -aux | grep dead_lock_demo

　　找出 dead_lock_demo 线程号，然后：

　　$> kill -11 pid

　　此时会生成core dump 文件，在我的系统上名字就是 core

　　然后调试：

　　$> gdb dead_lock_demo core

　　$> thread apply all bt

多线程死锁调试技巧：

http://www.cnblogs.com/zhuyp1015/p/3618863.html

refs：

http://stackoverflow.com/questions/18391808/getting-the-backtrace-for-all-the-threads-in-gdb

http://www.delorie.com/gnu/docs/gdb/gdb_25.html

http://stackoverflow.com/questions/1707167/how-extract-text-from-gdb

下面这个连接有其它的debug技巧，比如如何debug X Error，

https://wiki.debian.org/HowToGetABacktrace

gstack 脚本源码：

     https://github.com/bbannier/ROOT/blob/master/etc/gdb-backtrace.sh