使用 gdb 了解死锁行为答案

【问题标题】：Understanding deadlock behavior with gdb使用 gdb 了解死锁行为
【发布时间】：2014-01-09 10:35:15
【问题描述】：

我正在寻找死锁，但我不了解 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 获取锁（注意所有者）

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

线程 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，因此它们可能与它们的活动相关）？

【问题讨论】：

how reliable is the call to free()。如果你做一个测试。在 free 上设置一个断点，看看是否有任何对 free() 的调用来自 /usr/lib64/tls/libnvidia-tls.so.319.60？我的意思是重新启动您的应用程序，在 free 上设置断点并收集对 free() 的回溯（或仅从该库中）？
skwllsp：这样做实际上有点复杂。死锁的不是应用程序。这是一个持续数小时的测试套件，并且不会一直死锁，只是偶尔发生一次。此外，我怀疑如果我开始 gdbing 正在运行的套件，它会改变时间并且无处可去。
skwllsp：我只是不明白堆栈怎么会如此混乱，并引用显然不存在的代码。它是否真的损坏了，或者有什么我不知道的东西阻止我查看这些地址的位置和代码？动态加载？我不知道...
I simply don't understand how the stack can be so messed up and refer to code that apparently is not there。但这是我的观点。设置断点并获取堆栈跟踪只是为了确保在 deadlock() 之前从此库中调用 free 是正确的。你确定它们是正确的吗？
您确定所有共享库都存在吗？我的意思是info shared 显示

标签： gdb deadlock

【解决方案1】：

(gdb) disas 0x00002b67cbdeaded

没有函数包含指定的地址。这些地址上似乎没有任何内容。

您的结论可能不正确。试试(gdb) x/20i 0x00002b67cbdeaded-5，你会发现其实那里有代码，包括CALL pthread_mutex_lock。

可能发生的情况是您的程序中的某些内容正在使用 JIT 编译器，而调用 pthread_mutex_lock 的代码没有任何关联的符号（GDB 知道）。

该代码也没有任何展开描述符，这使得堆栈的其余部分完全不可靠。 free 和 malloc 可能实际在堆栈上，也可能不在堆栈上。

查看 /proc//maps 并查看 0x00002b67cbdea000 区域中映射的内容可能是说明性的。您很可能会找到具有rwxp 权限的匿名映射。

【讨论】：

What's likely happening is that something in your program is using a JIT compiler。正在运行的代码是 cPython，所有其他线程都显示符号及其所在位置。我没有尝试按照你说的去做，因为我因为其他原因不得不重新启动机器，因此我失去了死锁状态。它经常出现，所以我会再试一次。
你非常接近。我仍然不知道发生了什么，但至少我明白你说那个地址有东西是对的，它基本上是对跳转表的调用。所以堆栈没有损坏，只是编译器以“创造性的方式”使用它。我如何以及为什么会陷入僵局仍然是个谜。