обратная трассировка 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 не должно быть кода