gdb: 如何找到pthread_mutex_t死锁的owner

最新推荐文章于 2025-06-20 21:06:57 发布
最新推荐文章于 2025-06-20 21:06:57 发布
阅读量1.1k 收藏 30
点赞数 24
CC 4.0 BY-SA版权
分类专栏： GDB 文章标签： linux 服务器 gdb
版权声明：本文为博主原创文章，请勿转载。如无意间引用了他人成果，敬请指出，我会删除。
本文链接：https://blog.youkuaiyun.com/aspirestro/article/details/146954572

GDB 调试技巧：如何找到 pthread_mutex_t 死锁的 Owner

在多线程编程中，死锁是一个常见且棘手的问题。当两个或多个线程互相等待对方释放锁时，程序就会陷入死锁状态，导致所有相关线程都无法继续执行。为了快速定位死锁问题，调试工具 GDB 提供了强大的功能，允许我们深入分析线程和锁的状态。本文将介绍如何使用 GDB 命令 p ((pthread_mutex_t*) &buffer_lock)->__data.__owner 找到死锁的持有者（owner），并结合实际案例演示其用法。

1. 什么是死锁？

死锁是指多个线程因争夺资源而相互等待，最终导致所有线程都无法继续执行的情况。一个典型的死锁场景如下：

  • 线程 A 持有锁 Lock1，并尝试获取锁 Lock2。
  • 线程 B 持有锁 Lock2，并尝试获取锁 Lock1。

由于两个线程都在等待对方释放锁，程序陷入僵局。

2. 使用 GDB 分析死锁

在调试死锁问题时，我们需要回答以下几个关键问题：

  1. 哪些锁被持有？
  2. 每个锁的持有者是谁？
  3. 线程之间的依赖关系是什么？

GDB 提供了多种命令来帮助我们分析这些信息，其中 p ((pthread_mutex_t*) &buffer_lock)->__data.__owner 是一个非常实用的命令，用于查看某个互斥锁的持有者。

3. 命令解析
命令格式
p ((pthread_mutex_t*) &buffer_lock)->__data.__owner
逐部分解析

  1. p
    这是 GDB 中的 print 命令缩写，用于打印表达式的值。

  2. ((pthread_mutex_t*) &buffer_lock)
    将变量 buffer_lock 的地址强制转换为 pthread_mutex_t* 类型。假设 buffer_lock 是一个 pthread_mutex_t 类型的变量，这种转换确保我们可以访问其内部字段。

  3. ->__data.__owner

    • __data 是 pthread_mutex_t 内部的一个结构体字段，通常包含锁的状态信息。
    • __owner 是 __data 结构体中的一个字段，表示当前持有该锁的线程 ID。如果锁未被持有，则 __owner 的值通常为 0。
命令作用

这条命令的作用是：查看 buffer_lock 当前是否被某个线程持有，并输出持有该锁的线程 ID。

4. 实际案例分析
示例代码

以下是一个可能导致死锁的简单示例：

#include <pthread.h>
#include <stdio.h>
#include <unistd.h>

pthread_mutex_t lock1, lock2;

void* thread1_func(void* arg) {
    pthread_mutex_lock(&lock1);
    printf("Thread 1: Acquired lock1\n");
    sleep(1); // 模拟工作
    pthread_mutex_lock(&lock2); // 可能导致死锁
    printf("Thread 1: Acquired lock2\n");
    pthread_mutex_unlock(&lock2);
    pthread_mutex_unlock(&lock1);
    return NULL;
}

void* thread2_func(void* arg) {
    pthread_mutex_lock(&lock2);
    printf("Thread 2: Acquired lock2\n");
    sleep(1); // 模拟工作
    pthread_mutex_lock(&lock1); // 可能导致死锁
    printf("Thread 2: Acquired lock1\n");
    pthread_mutex_unlock(&lock1);
    pthread_mutex_unlock(&lock2);
    return NULL;
}

int main() {
    pthread_t t1, t2;
    pthread_mutex_init(&lock1, NULL);
    pthread_mutex_init(&lock2, NULL);

    pthread_create(&t1, NULL, thread1_func, NULL);
    pthread_create(&t2, NULL, thread2_func, NULL);

    pthread_join(t1, NULL);
    pthread_join(t2, NULL);

    pthread_mutex_destroy(&lock1);
    pthread_mutex_destroy(&lock2);
    return 0;
}
运行程序

编译并运行上述代码：

gcc -g -o deadlock_example deadlock_example.c -lpthread
./deadlock_example

程序可能会卡住，无法继续执行。

使用 GDB 调试

  1. 启动 GDB 并加载程序：

    gdb ./deadlock_example

  2. 设置断点并运行程序：

    break thread1_func
break thread2_func
run

  3. 当程序卡住时，暂停执行并检查锁状态：

    thread apply all bt  # 查看所有线程的调用栈
p ((pthread_mutex_t*) &lock1)->__data.__owner  # 查看 lock1 的持有者
p ((pthread_mutex_t*) &lock2)->__data.__owner  # 查看 lock2 的持有者
分析结果

假设输出如下：

$1 = 140735218956032  # lock1 的持有者线程 ID
$2 = 140735218956352  # lock2 的持有者线程 ID

通过 info threads 命令可以进一步确认线程 ID 对应的线程：

info threads

结合调用栈信息，可以清晰地看到：

  • 线程 1 持有 lock1 并试图获取 lock2。
  • 线程 2 持有 lock2 并试图获取 lock1。

这就是典型的死锁场景。

5. 实战记录

~# gdb ./hello
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2
Copyright © 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type “show copying” and “show warranty” for details.
This GDB was configured as “aarch64-linux-gnu”.
Type “show configuration” for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.

For help, type “help”.
Type “apropos word” to search for commands related to “word”…
Reading symbols from ./hello…
(gdb) b main
Breakpoint 1 at 0x12c4: file hello.c, line 78.
(gdb) run
Starting program: /root/hello
[Thread debugging using libthread_db enabled]
Using host libthread_db library “/lib/aarch64-linux-gnu/libthread_db.so.1”.
[New Thread 0x7ff7a7a1c0 (LWP 1657)]

Thread 1 “hello” hit Breakpoint 1, main () at hello.c:78
78 pthread_create(&master, NULL, &master_thread, NULL);
(gdb) disassemble rt_print_flush_buffers
Dump of assembler code for function rt_print_flush_buffers:
0x0000007ff7fa2ea8 <+0>: stp x29, x30, [sp, #-32]!
0x0000007ff7fa2eac <+4>: mov x29, sp
0x0000007ff7fa2eb0 <+8>: str x19, [sp, #16]
0x0000007ff7fa2eb4 <+12>: adrp x19, 0x7ff7fca000 memcpy@got.plt
0x0000007ff7fa2eb8 <+16>: add x19, x19, #0xed0
0x0000007ff7fa2ebc <+20>: bl 0x7ff7f9e070 cobalt_thread_relax@plt
0x0000007ff7fa2ec0 <+24>: add x19, x19, #0x8
0x0000007ff7fa2ec4 <+28>: mov x0, x19
0x0000007ff7fa2ec8 <+32>: bl 0x7ff7f9e730 pthread_mutex_lock@plt
0x0000007ff7fa2ecc <+36>: bl 0x7ff7fa2ca0 <print_buffers>
0x0000007ff7fa2ed0 <+40>: mov x0, x19
0x0000007ff7fa2ed4 <+44>: ldr x19, [sp, #16]
0x0000007ff7fa2ed8 <+48>: ldp x29, x30, [sp], #32
0x0000007ff7fa2edc <+52>: b 0x7ff7f9e7c0 pthread_mutex_unlock@plt
End of assembler dump.
(gdb) break *0x0000007ff7fa2ecc
Breakpoint 2 at 0x7ff7fa2ecc
(gdb) break release_buffer
Breakpoint 3 at 0x7ff7fa301c
(gdb) c
Continuing.
[New Thread 0x7ff72791c0 (LWP 1658)]
[New Thread 0x7ff72581c0 (LWP 1659)]
[Switching to Thread 0x7ff72581c0 (LWP 1659)]

Thread 4 “slave” hit Breakpoint 2, 0x0000007ff7fa2ecc in rt_print_flush_buffers () from /usr/xenomai/lib/libcobalt.so.2
(gdb) p ((pthread_mutex_t*) &buffer_lock)->__data.__owner
$1 = 1659
(gdb) call pthread_cancel(0x7ff72581c0)
$2 = 0
(gdb) c
Continuing.

Thread 4 “slave” hit Breakpoint 3, 0x0000007ff7fa301c in release_buffer () from /usr/xenomai/lib/libcobalt.so.2
(gdb) p ((pthread_mutex_t*) &buffer_lock)->__data.__owner
$3 = 1659
(gdb) c
Continuing.
^C
Thread 1 “hello” received signal SIGINT, Interrupt.
[Switching to Thread 0x7ff7ff4010 (LWP 1654)]
0x0000007ff7bb6398 in sched_yield () at …/sysdeps/unix/syscall-template.S:78
78 …/sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) info thread
Id Target Id Frame

  • 1 Thread 0x7ff7ff4010 (LWP 1654) “hello” 0x0000007ff7bb6398 in sched_yield () at …/sysdeps/unix/syscall-template.S:78
    2 Thread 0x7ff7a7a1c0 (LWP 1657) “cobalt_printf” __lll_lock_wait (futex=futex@entry=0x7ff7fcaed8 <buffer_lock>, private=0)
    at lowlevellock.c:52
    3 Thread 0x7ff72791c0 (LWP 1658) “master” 0x0000007ff7b6d314 in __GI__IO_default_xsputn (n=, data=,
    f=) at genops.c:393
    4 Thread 0x7ff72581c0 (LWP 1659) “slave” (Exiting) __lll_lock_wait (futex=futex@entry=0x7ff7fcaed8 <buffer_lock>, private=0)
    at lowlevellock.c:52
    (gdb) thread 4
    [Switching to thread 4 (Thread 0x7ff72581c0 (LWP 1659))]
    #0 __lll_lock_wait (futex=futex@entry=0x7ff7fcaed8 <buffer_lock>, private=0) at lowlevellock.c:52
    52 lowlevellock.c: No such file or directory.
    (gdb) bt
    #0 __lll_lock_wait (futex=futex@entry=0x7ff7fcaed8 <buffer_lock>, private=0) at lowlevellock.c:52
    #1 0x0000007ff7f43cd8 in __GI___pthread_mutex_lock (mutex=0x7ff7fcaed8 <buffer_lock>) at pthread_mutex_lock.c:80
    #2 0x0000007ff7fa3038 in release_buffer () from /usr/xenomai/lib/libcobalt.so.2
    #3 0x0000007ff7f413c0 in __nptl_deallocate_tsd () at pthread_create.c:301
    #4 0x0000007ff7f4156c in start_thread (arg=0x7ff7fa7430 <cobalt_thread_trampoline>) at pthread_create.c:488
    #5 0x0000007ff7bcc49c in thread_start () at …/sysdeps/unix/sysv/linux/aarch64/clone.S:78
    (gdb) p ((pthread_mutex_t*) &buffer_lock)->__data.__owner
    $4 = 1659
    (gdb) p ((pthread_mutex_t*) &buffer_lock)->__data.__lock
    $5 = 2
    (gdb) p ((pthread_mutex_t*) &buffer_lock)->__data.__count
    $6 = 0
    (gdb)
6. 注意事项

  1. 平台差异性
    上述命令依赖于 pthread_mutex_t 的具体实现。不同平台或线程库可能有不同的字段名称或结构布局。例如，在某些系统上，__data 和 __owner 可能不存在，需要查阅对应平台的头文件（如 pthread.h）以确认字段名称。

  2. 调试符号要求
    使用 GDB 调试时，必须确保编译时启用了调试符号（-g 选项）。否则，GDB 无法访问变量的内部结构。

  3. 线程安全
    在调试过程中，尽量避免修改锁的状态，以免影响程序的正常运行。

7. 总结

通过 GDB 命令 p ((pthread_mutex_t*) &buffer_lock)->__data.__owner，我们可以快速找到死锁的持有者线程，从而更好地理解问题的本质。这种方法不仅适用于简单的死锁场景，还可以扩展到更复杂的多线程调试任务中。

当然，这只是调试多线程程序的一个小技巧。要真正掌握多线程编程，还需要深入理解线程同步机制、锁的使用原则以及并发编程的最佳实践。希望本文能为你提供一些启发，并在实际开发中助你一臂之力！

用gdb脚本解决死锁的调试方法(由pthread_mutex_lock引起的死锁)
蔚蓝的天空Tom
06-30 4778
首先给出gdb定位死锁的脚本： #deadlock_debug_gdb.cmd set pagination off set logging file gdb.log set logging overwrite set logging on start set $lock_addr=pthread_mutex_lock set $unlock_addr=pthread_mutex
4.线程的取消/清理/互斥锁
不会编程喵的博客
10-14 684
在Linux中，互斥锁并不占用任何资源，因此LinuxThreads中的 pthread_mutex_destroy()除了检查锁状态以外（锁定状态则返回EBUSY）没有其他动作。写者：写者使用写锁，如果当前没有读者，也没有其他写者，写者立即获得写锁；否则写者将等待，直到没有读者和写者。读写锁出于写锁状态时，所有试图对读写锁加锁的线程，不管是读者试图加读锁，还是写者试图加写锁，都会被阻塞。读写锁处于读锁状态时，有写者试图加写锁时，之后的其他线程的读锁请求会被阻塞，以避免写者长时间的不写锁。
Linux GDB分析死锁
Dayu_log的博客
10-04 428
死锁
GDB排查死锁问题
微鉴道长的博客
08-23 2007
gdb排查死锁问题
【学习笔记】锁+死锁+gdb调试死锁
最新发布
m0_51429770的博客
06-20 1056
锁+死锁的相关知识学习
LInux gdb 分析死锁
sz76211822的专栏
12-22 2462
基于公司的代码分析的死锁，界面卡死不能操作，没有崩溃退出，那么首先是附加进程： 第一步：找到进程 ps -aux | grep MonitorClient 第二步：附加进程 第三步：查看堆栈 bt 第四步：执行了bt后，打印出来了界面卡死的堆栈 出现死锁了，查看代码在函数下有个自动锁 第五步：进入CVideoPlayManager::ShowBottomRightText这个函数 f 4 第六步：查看锁被哪个线程拿住了 p m_PortDis...
GDB之死锁排查
tianyexing2008的博客
03-11 2996
多线程中遇到的常见“死锁”可能有两种情况：1，自身线程等锁（这个应该不叫死锁）；2，两个线程相互等对方的锁。 下面就两种情况分别举例：不管哪种情况，出现的时候首先查看函数调用栈，查找函数__lll_lock_wait。 1，本线程内等锁 出现这种情况一般是在一个函数里加锁了，在调用其他的函数里也加锁了，这样就像是嵌套加锁，导致卡死。 通过查看互斥锁变量值中的__owner可以得出，这个互斥锁所属线程为782，其实就是当前线程。我这个是在项目代码中模拟死锁加的代码。这是已经知道互斥锁变量名称的情况
利用GDB分析死锁问题
sinat_32152141的博客
05-31 2059
互斥条件：资源是独占的且排他使用，进程互斥使用资源，即任意时刻一个资源只能给一个进程使用，其他进程若申请一个资源，而该资源被另一进程占有时，则申请者等待直到资源被占有者释放。 不可剥夺条件：进程所获得的资源在未使用完毕之前，不被其他进程强行剥夺，而只能由获得该资源的进程资源释放。 请求和保持条件：进程每次申请它所需要的一部分资源，在申请新的资源的同时，继续占用已分配到的资源。在发生死锁时必然存在一个进程等待队列{P1,P2,…,Pn},其中P1等待P2占有的资源，P2等待P3占有的资源，…，Pn等待P1占有
【Linux】线程安全：死锁（附加gdb调试分析）
Dooo_yh的博客
06-04 978
线程安全的死锁分析 gdb调试指令的展示
pthread_mutex_lock的错误检查如何进行
02-26
fprintf(stderr, "检测到死锁：线程重复加锁\n"); break; default: fprintf(stderr, "未知错误: %s\n", strerror(ret)); } // 根据错误类型处理（如释放资源、终止线程等） exit(EXIT_FAILURE); } // 加锁...
native 解析死锁方法
aa787282301的博客
03-06 6094
一. 概述 我们平时在分析system_server watchdog问题时有时候会遇到一些native层的死锁问题，正常情况下我们是把所有可疑的线程调用栈全部通过symbols找到可以的死锁线程，这个方法比较耗费体力和脑力。这篇文章将会教会你一个更为简便的方法我们通过gdb调试直接打印出对应吃锁的线程。 二.通过GDB查看线程锁 我们通过aosp代码找到锁的定义：h...
pthread_mutex_lock.c:67产生段错误
09-14
根据引用中对互斥锁的描述，互斥锁是用来保护共享资源的。当一个线程获得了互斥锁后，其他线程需要等待，直到锁被释放才能去...请根据以上步骤逐个排查，找到并解决pthread_mutex_lock.c文件第67行产生段错误的问题。
gdb分析死锁
qq_41962968的博客
10-04 1020
Pn},其中P1等待P2占有的资源，P2等待P3占有的资源，…破坏“不可剥夺”条件：一个进程不能获得所需要的全部资源时便处于等待状态，等待期间他占有的资源将被隐式的释放重新加入到 系统的资源列表中，可以被其他的进程使用，而等待的进程只有重新获得自己原有的资源以及新申请的资源才可以重新启动，执行。破坏“循环等待”条件：采用资源有序分配其基本思想是将系统中的所有资源顺序编号，将紧缺的，稀少的采用较大的编号，在申请资源时必须按照编号的顺序进行，一个进程只有获得较小编号的进程才能申请较大编号的进程。
GDB 查看死锁
06-28 8175
死锁：一种情形，此时执行程序中两个或多个线程发生永久堵塞（等待），每个线程都在等待被   其他线程占用并堵塞了的资源。例如，如果线程A锁住了记录1并等待记录2，而线程B锁住了记录2并等待记录1，这样两个线程就发生了死锁现象。 gdb调试死锁的方法： gdb  attach pid thread apply all bt 找到_lll_lo
gdb检测死锁
程序员的规则
09-26 437
gdb调试死锁
【Linux】线程安全-死锁
weixin_56916549的博客
09-01 480
死锁问题 场景1 场景2 死锁的gdb调试 造成死锁的必要条件 不可剥夺 循环等待 互斥条件 请求和保持 预防死锁 破坏必要条件，循环等待&请求和保持 加锁顺序一致 避免锁没有被释放 资源一次性分配
C++(Qt)软件调试---线程死锁调试（15）
mahuifa的博客
10-25 2484
死锁是一种情况，其中两个或多个线程（或进程）相互等待对方释放资源，导致它们都无法继续执行。这是一种非常令人头疼的问题，因为它可以导致程序挂起，无法继续运行。 本文中会详细讲述linux、Windows下调试C++线程死锁、Qt线程死锁的方式。
Linux kernel: How to debug mutex deadlock 如何调试mutex死锁
weixin_30596343的博客
04-09 306
和userspace调试lock一样，主要是要：1. 找到lock死锁的地方，打印出调用栈2. 找出这个mutex目前被谁占用了针对1：在kernel config中，Kernel Hacking这个大项中，enable跟lock/mutex相关的config，比如CONFIG_DEBUG_MUTEX，以及CONFIG_DETECT_HUNG_TASKS, 这样当死锁发生时，稍微等待一段时间（默...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值