用gdb理解死锁行为

我正在寻找一个僵局，但我不理解gdb在这方面的行为。我有两条线索：

Thread 2 (Thread 0x2aaaadf66940 (LWP 10229)):
#0  0x0000003f95e0d654 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x0000003f95e08f65 in _L_lock_1127 () from /lib64/libpthread.so.0
#2  0x0000003f95e08e63 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x00002b67cbdeaded in ?? ()
#4  0x000000002d0e9608 in ?? ()
#5  0x00002b67cbd1e1f2 in ?? ()
#6  0x000000000000000b in ?? ()
#7  0x00002aaaca08e410 in ?? ()
#8  0x00002aaab405d558 in ?? ()
#9  0x00002aaaadf65f48 in ?? ()
#10 0x00002aaaadf65fa0 in ?? ()
#11 0x00002aaaadf65fc0 in ?? ()
#12 0x00002aaaadf65f40 in ?? ()
#13 0x00002aaaadf65f50 in ?? ()
#14 0x000000002d0e7460 in ?? ()
#15 0x0000000026014330 in ?? ()
#16 0x00002b67cc1d08b0 in ?? ()
#17 0x0000003f94e7587b in free () from /lib64/libc.so.6
#18 0x00002aaac8b67450 in ?? ()
#19 0x00002aaaadf66070 in ?? ()
#20 0x13477fb9fe21aee8 in ?? ()
#21 0x000003742e856f43 in ?? ()
#22 0x00002b67cbe11811 in ?? ()
#23 0x00002b67cc1cfc70 in ?? ()
#24 0x000000002d0e8328 in ?? ()
#25 0x000000002d0e9630 in ?? ()
#26 0x00002b67cbded355 in ?? ()
#27 0x0000000052cdceee in ?? ()
#28 0x000000002d0e9608 in ?? ()
#29 0x0000000000000001 in ?? ()
#30 0x000000002d0e9700 in ?? ()
#31 0x000000002d0e96a8 in ?? ()
#32 0x000000002d0e9728 in ?? ()
#33 0x000000002d0e9630 in ?? ()
#34 0x00002b67cbded538 in ?? ()
#35 0x000000002ccbc6a8 in ?? ()
#36 0x00002aaaadf66070 in ?? ()
#37 0xfffffffffffffffe in ?? ()
#38 0x0000000000000008 in ?? ()
#39 0x00002b67cbe0cf00 in ?? ()
#40 0x0000003b24002216 in ?? () from /usr/lib64/tls/libnvidia-tls.so.319.60
#41 0x00002b67cbe116ec in ?? ()
#42 0x000000002d0e9648 in ?? ()
#43 0xffffffffffffff01 in ?? ()
#44 0x00002b67cc1f38f8 in ?? ()
#45 0x00002b67cbe103fa in ?? ()
#46 0x0000000019eac470 in ?? ()
#47 0x0000000034bc8ef0 in ?? ()
#48 0x00000000ffffffff in ?? ()
#49 0x0000000000000000 in ?? ()

Thread 1 (Thread 0x2b67c311c600 (LWP 9798)):
#0  0x0000003f95e0d654 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x0000003f95e08f4a in _L_lock_1034 () from /lib64/libpthread.so.0
#2  0x0000003f95e08e0c in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x00002b67cbdf02a8 in ?? ()
#4  0x000000000000b000 in ?? ()
#5  0x000000000000b000 in ?? ()
#6  0x000000002d0e7460 in ?? ()
#7  0x00002aaad484e6c0 in ?? ()
#8  0x00007fffd540a1b0 in ?? ()
#9  0x0000003f94e73f0e in malloc () from /lib64/libc.so.6
#10 0x0000003b24002216 in ?? () from /usr/lib64/tls/libnvidia-tls.so.319.60
#11 0x0000000000000000 in ?? ()

这两个线程显然是死锁的：线程1希望从线程2获得锁（注意所有者）

线程2想要从线程1获取锁

(gdb) p *(pthread_mutex_t*)0x2d0e8330
$2 = {__data = {__lock = 2, __count = 1, __owner = 9798, __nusers = 1, __kind = 1, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, 

现在，我不明白的是，为什么回溯线会被破坏。我尝试检查哪些库映射到这些地址（特别是2b67cbd），但没有一个映射到这些地址。我试了一个disas。运气不好：

 (gdb) disas 0x00002b67cbdeaded
 No function contains specified address.

那些地址上似乎什么都没有。我原以为这是堆栈损坏，但实际上调用pthread锁的是什么呢？谁将线程发送到该代码？对free（）的调用有多可靠（请注意，另一个线程正在调用malloc，因此它们的活动可能相关）

（gdb）禁用0x00002B67CBheaded

没有函数包含指定的地址。 那些地址上似乎什么都没有

你的结论可能不正确。尝试

（gdb）x/20i 0x00002b67cbheaded-5

，您将看到实际上那里有代码，包括

调用pthread\u mutex\u lock

可能发生的情况是，程序中的某些东西正在使用JIT编译器，而调用

pthread\u mutex\u lock

的代码没有任何与之相关联的符号（GDB知道）

该代码也没有任何展开描述符，这使得堆栈的其余部分完全不可靠

free

和

malloc

可能在堆栈上，也可能不在堆栈上

查看/proc//maps并查看

0x00002b67cbdea000

区域中映射的内容可能是说明性的。您很可能会找到具有

rwxp

权限的匿名映射

（gdb）禁用0x00002B67CBheaded

没有函数包含指定的地址。 那些地址上似乎什么都没有

你的结论可能不正确。尝试

（gdb）x/20i 0x00002b67cbheaded-5

，您将看到实际上那里有代码，包括

调用pthread\u mutex\u lock

可能发生的情况是，程序中的某些东西正在使用JIT编译器，而调用

pthread\u mutex\u lock

的代码没有任何与之相关联的符号（GDB知道）

该代码也没有任何展开描述符，这使得堆栈的其余部分完全不可靠

free

和

malloc

可能在堆栈上，也可能不在堆栈上

---

查看/proc//maps并查看

0x00002b67cbdea000

区域中映射的内容可能是说明性的。您很可能会找到具有

rwxp

权限的匿名映射。

对free（）的调用有多可靠。

。如果你做一个测试呢。在free上设置一个断点，查看是否有对free（）的调用来自/usr/lib64/tls/libnvidia-tls.so.319.60？我的意思是重新启动你的应用程序，在free上设置一个断点并收集free（）的回溯（或者只从这个库）？skwllsp：这样做实际上有点复杂。死锁的不是应用程序。这是一个持续数小时的测试套件，不会一直死锁，只是偶尔死锁一次。另外，我怀疑如果我开始gdbing运行的套件，它会改变时间安排，并且不会有任何进展。skwllsp：我只是不明白为什么堆栈会如此混乱，并引用显然不存在的代码。它是否真的被破坏了，或者有什么我不知道的东西阻止我查看这些地址上的位置和代码？动态加载？我不知道…

我只是不明白堆栈怎么会如此混乱，引用的代码显然不存在

。但这是我的观点。设置断点并获取stacktraces，以确保在死锁（）发生之前从该库释放的调用是正确的。您确定它们是正确的吗？您确定所有共享库都存在吗？我的意思是，

info shared

显示了对free（）的调用有多可靠。如果你做一个测试呢。在free上设置一个断点，查看是否有对free（）的调用来自/usr/lib64/tls/libnvidia-tls.so.319.60？我的意思是重新启动你的应用程序，在free上设置一个断点并收集free（）的回溯（或者只从这个库）？skwllsp：这样做实际上有点复杂。死锁的不是应用程序。这是一个持续数小时的测试套件，不会一直死锁，只是偶尔死锁一次。另外，我怀疑如果我开始gdbing运行的套件，它会改变时间安排，并且不会有任何进展。skwllsp：我只是不明白为什么堆栈会如此混乱，并引用显然不存在的代码。它是否真的被破坏了，或者有什么我不知道的东西阻止我查看这些地址上的位置和代码？动态加载？我不知道…

我只是不明白堆栈怎么会如此混乱，引用的代码显然不存在

。但这是我的观点。设置断点并获取stacktraces，以确保在死锁（）发生之前从该库释放的调用是正确的。您确定它们是正确的吗？您确定所有共享库都存在吗？我的意思是

info shared

显示

可能发生的情况是程序中的某些东西正在使用JIT编译器。正在运行的代码是cPython，所有其他线程都显示symbol和它们所在的位置。我没有像你说的那样做，因为我因为其他原因不得不重新启动机器，因此我失去了死锁状态。它经常出现，所以我会再试一次。你很接近。我仍然不知道发生了什么，但至少我明白你说的是对的，在那个地址有一些东西，基本上是对跳转表的调用。所以堆栈没有损坏，只是
 (gdb) disas 0x00002b67cbdeaded
 No function contains specified address.