话说谁能生巧。以前由于经常被拉去定位疑难杂症,gdb用的还算熟练。最近年把因工作内容的调整,gdb很少用,前些日子定位问题时发现曾经很熟悉的东西都有点陌生了。因此决定把以前整理的一些小经验、技巧再回顾一下,并分享给大家。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
debug 版本的应用程序发生死锁,可以将pthread_mutex_t打印出来,查看其中的owner字段即可知道锁被哪个线程持有。
release版本的程序,由于进行了优化,可能无法直接打出锁变量。 这里介绍一个简单方法,可以查看release版(当然也支持debug)的锁状态,以便快速定位死锁问题。
操作步骤
1) gdb attach 到死锁的进程.
例如 gdb –p 2456
2) thread 命令切换到等待锁(这里主要指Mutex,暂不考虑读写锁)的某个线程。 可以结合 info thr、thr apply all bt 等命令确定哪些线程在等锁。
3) bt 查看该线程堆栈
(gdb) bt
#0 0x00110424 in __kernel_vsyscall ()
#1 0x0062d019 in __lll_lock_wait () from /lib/libpthread.so.0
#2
Linux发布版死锁定位:GDB调试技巧

本文分享了如何在Linux的Release版本中定位死锁问题的调试经验。通过GDB附加到死锁进程,切换线程,查看锁状态,并分析堆栈,可以有效地找出死锁的位置。主要步骤包括:使用gdb attach到进程,通过thread和info thr命令确定等待锁的线程,查看锁的owner字段,结合代码分析定位死锁。注意,此方法适用于32bit系统的pthread_mutex_t死锁,对于64位系统和读写锁,方法有所不同。
最低0.47元/天 解锁文章
935

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



