обратная трассировка GDB и pthread_cond_wait ()

Question

Это на машине Redhat EL5 с ядром 2.6.18-164.2.1.el5 x86_64 с использованием gcc 4.1.2 и gdb 7.0.

Когда я запускаю свое приложение с помощью gdb и врываюсь во время его работы, некоторые из моих потоков показывают следующий стек вызовов, когда я выполняю обратную трассировку:

#0  0x000000000051d7da in pthread_cond_wait ()
#1  0x0000000100000000 in ?? ()
#2  0x0000000000c1c3b0 in ?? ()
#3  0x0000000000c1c448 in ?? ()
#4  0x00000000000007dd in ?? ()
#5  0x000000000051d630 in ?? ()
#6  0x00007fffffffdc90 in ?? ()
#7  0x000000003b1ae84b in ?? ()
#8  0x00007fffffffdd50 in ?? ()
#9  0x0000000000000000 in ?? ()

Является ли это симптомом общей проблемы?
Известна ли проблема с просмотром стека вызовов во время ожидания условия?

Answer 1

Проблема в том, что pthread_cond_wait написано в сборке с ручным кодированием и, по-видимому, не имеет надлежащего дескриптора размотки (необходим для x86_64 для размотки стека) в вашей сборке glibc. Эта проблема, возможно, недавно была исправлена ​​ здесь .

Вы можете попробовать собрать и установить последнюю версию glibc (примечание: если вы испортите установку, ваша машина, вероятно, станет не загружаемой; подходите с особой осторожностью!), Или просто используйте «поддельные» следы стека из pthread_cond_wait.

Answer 2

Как правило, синхронизация требуется, когда несколько потоков совместно используют один ресурс. В таком случае, когда вы прервете программу, вы увидите, что работает только 1 поток (т. Е. Доступ к ресурсу), а другие потоки ожидают в пределах pthread_cond_wait().

Так что я не думаю, что pthread_cond_wait() само по себе проблематично.

Если ваша программа зависает с тупиком или производительность не масштабируется, это может быть вызвано pthread_cond_wait().

Answer 3

Для меня это выглядит как испорченный след

например:

#9  0x0000000000000000 in ?? ()

Не должно быть кода в NULL