今天遇到一个lll_lock_wait的问题，分析之后得到的结论是死锁，觉得挺有意义的，值得把分析过程记录一下，顺便梳理Gdb调试程序的一般步骤。

一般，程序核心转储之后会生成一个core文件，可使用命令

gdb program core.xxx

调试，如果执行程序被扒了衣服(stripped)，则最好将符号表文件也放在程序同一目录，以得到更多详细信息。

可先整体查看该进程下所有线程信息

info threads

或者，打印所有线程堆栈

thread apply all bt

切换到线程30，可执行

t 30

打印该线程的堆栈信息

bt

选择frame命令查看第五帧

f 5

打印当前类所有成员的值

set print pretty

p *this

当时gdb调试信息类似下面这样

 (gdb) info thread 
  5 Thread 0x41e37940 (LWP 6722)  0x0000003d1a80d4c4 in __lll_lock_wait () 
  from /lib64/libpthread.so.0 
  4 Thread 0x42838940 (LWP 6723)  0x0000003d1a80d4c4 in __lll_lock_wait () 
  from /lib64/libpthread.so.0 
  3 Thread 0x43239940 (LWP 6724)  0x0000003d19c9a541 in nanosleep () 
 from /lib64/libc.so.6 
  2 Thread 0x43c3a940 (LWP 6725)  0x0000003d19c9a541 in nanosleep () 
 from /lib64/libc.so.6 
  1 Thread 0x2b984ecabd90 (LWP 6721)  0x0000003d1a807b35 in pthread_join () 
 from /lib64/libpthread.so.0

很多时候程序并没有coredump，我们也可以gcore出来，或者干脆attach进程号，关于gdb调试其实有很多内容，程序调试也是件需要毅力、耐心和观察力的累活，就像侦探一样，从蛛丝马迹之中找寻真相。