使用 gdb 了解死锁行为

Ste*_*ini 3 gdb deadlock

我正在寻找僵局,但我不理解 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 ?? ()
Run Code Online (Sandbox Code Playgroud)

这两个线程显然是死锁的:线程 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}}, 
Run Code Online (Sandbox Code Playgroud)

线程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}}, 
Run Code Online (Sandbox Code Playgroud)

现在,我不明白的是为什么回溯如此破碎。我尝试检查哪些库映射到这些地址(特别是 2b67cbd),但没有一个这样做。我尝试了一个disas。没有运气:

 (gdb) disas 0x00002b67cbdeaded
 No function contains specified address.
Run Code Online (Sandbox Code Playgroud)

这些地址上似乎没有任何内容。我以为这是堆栈损坏,但是实际调用 pthread 锁时发生了什么?谁将线程发送到该代码?对 free() 的调用有多可靠(请注意,另一个线程正在调用 malloc,因此它们的活动可能相关)?

Emp*_*ian 5

(gdb) disas 0x00002b67cbdeaded

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

你的结论可能不正确。尝试一下(gdb) x/20i 0x00002b67cbdeaded-5,您会发现实际上那里有代码,包括一个CALL pthread_mutex_lock.

可能发生的情况是,您的程序中的某些内容正在使用 JIT 编译器,并且调用的代码pthread_mutex_lock没有任何与之关联的符号(GDB 知道)。

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

查看 /proc//maps 并查看该0x00002b67cbdea000区域中映射的内容可能会很说明问题。您很可能会发现具有rwxp权限的匿名映射。

  • 你们非常接近。我仍然不知道发生了什么,但至少我明白你说的在那个地址有东西是对的,它基本上是对跳转表的调用。所以堆栈并没有被破坏,只是编译器以“创造性的方式”使用了它。如何以及为何陷入僵局仍然是个谜。 (2认同)