Понимание поведения взаимоблокировки с gdb

Я ищу тупик, но я не понимаю поведения 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 ??()

Эти две нити, по-видимому запиранием: Thread 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), но никто этого не делает. Я попробовал дезак. нет удачи:

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

На этих адресах, похоже, ничего нет. Я думал, что это была коррупция в стеке, но потом что происходит, что на самом деле вызывает блокировку pthread? Кто отправляет поток этому коду? и насколько надежным является вызов free() (обратите внимание, что другой поток выполняет вызов для malloc, поэтому они могут быть связаны в их активности)?

источник

2014-01-09 Stefano Borini

'насколько надежным является вызов free()'. Что делать, если вы делаете тест. Установите точку останова на бесплатную и посмотрите, есть ли какие-либо вызовы free() из /usr/lib64/tls/libnvidia-tls.so.319.60? Я имею в виду перезапуск приложения, установив точку останова на бесплатную и собирающую обратные трассы на free() (или только из этой библиотеки)? –

skwllsp: На самом деле это немного сложно сделать. Это не приложение, которое блокирует. Это testuite, который длится много часов и не затормозит все время, только время от времени. Кроме того, у меня есть подозрение, что если я начну gdbing запущенного пакета, он изменит тайминги и не приведет нигде. –

skwllsp: Я просто не понимаю, как стек может быть перепутан и ссылаться на код, который, по-видимому, отсутствует. Действительно ли это повреждено, или что-то, о чем я не знаю, не позволяет мне узнать, где и какой код присутствует на этих адресах? Динамическая загрузка? Я не знаю ... –

(gdb) disas 0x00002b67cbdeaded

Функция не содержит указанный адрес. На этих адресах, похоже, ничего нет.

Возможно, ваш вывод неверен. Попробуйте (gdb) x/20i 0x00002b67cbdeaded-5, и вы увидите, что на самом деле там есть код, включая CALL pthread_mutex_lock.

Возможно, что-то в вашей программе использует JIT-компилятор, а код, который вызывает pthread_mutex_lock, не имеет никаких символов (которые GDB знает), связанных с ним.

В этом коде также нет дескрипторов разматывания, что делает остальную часть стека совершенно ненадежной. free и malloc могут быть или не быть фактически на стеке.

Это может быть иллюстрацией для просмотра/proc/maps и просмотра того, что отображается в регионе 0x00002b67cbdea000. Скорее всего, вы найдете анонимное сопоставление с разрешениями rwxp.

источник

2014-01-10 03:09:56

'Что, скорее всего, происходит в том, что что-то в вашей программе использует JIT-компилятор'. выполняемый код - cPython, а все остальные потоки показывают символ и где они находятся. Я не пытался делать так, как вы сказали, потому что мне пришлось перезагружать машину по другим причинам, и поэтому я потерял условие взаимоблокировки. Он представляет себя довольно часто, поэтому я попробую еще раз. –

Вы были совсем рядом. Я до сих пор не знаю, что происходит, но, по крайней мере, я понял, что вы правы, говоря, что есть что-то по этому адресу, и это в основном призыв к таблице прыжков. Таким образом, стек не поврежден, просто он используется в «творческом ключе» компилятором. Как и почему я зашел в тупик, все еще остается загадкой. –

Понимание поведения взаимоблокировки с gdb

ответ

Смежные вопросы