本案例借着gdb调试死锁的问题,演示在多线程场景下如何使用gdb调试多线程死锁的
调试过程:
1.为了重现死锁现象,自己写了个死锁demo
[root@localhost bin]# ./deadLock
thread_routine_two:lock mutex two
thread_routine_one:lock mutex one
thread_routine_one:lock mutex two
thread_routine_two:lock mutex one
2. 使用pstack和gdb命令配合来定位问题具体出在哪里
[root@localhost ~]# pstack
Usage: pstack <process-id>
[root@localhost ~]# ps -ef|grep deadLock |grep -v grep
root 14759 10973 0 10:06 pts/0 00:00:00 ./deadLock
[root@localhost ~]# pstack 14759 #这里可以看到进程有一个主线程加两个子线程,判断是否卡死可以多次执行,如果有线程堆栈一直没变化,基本可以确定是该线程卡死
Thread 3 (Thread 0x7f0e309c0700 (LWP 14760)):
#0 0x00007f0e30d9c4ed in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x00007f0e30d97dcb in _L_lock_883 () from /lib64/libpthread.so.0
#2 0x00007f0e30d97c98 in pthread_mute

本文通过实例演示了如何使用gdb调试工具诊断并解决了一个死锁问题,展示了在多线程环境下跟踪线程状态和定位锁竞争导致的死锁点的过程。
最低0.47元/天 解锁文章
261

被折叠的 条评论
为什么被折叠?



