gdb backtrace et pthread_cond_wait()

Question

Ceci est sur une machine Redhat EL5 avec un noyau 2.6.18-164.2.1.el5 x86_64 utilisant gcc 4.1.2 et gdb 7.0.

Quand je lance ma demande avec gdb et rupture dans pendant son exécution, plusieurs de mes fils montrent la pile d'appel suivant quand je fais un backtrace:

#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 ??() 

Est-ce un symptôme d'un problème commun?
Existe-t-il un problème connu de visualisation de la pile d'appels en attente d'une condition?

Answer 1

Le problème est que pthread_cond_wait est écrit dans l'assembly codé à la main et n'a apparemment pas de descripteur de déroulement approprié (requis sur x86_64 pour dérouler la pile) dans votre build de glibc. Ce problème a peut-être été corrigé récemment here.

Vous pouvez essayer de construire et d'installer la dernière glibc (remarque: si vous bousiller l'installation, votre machine deviendra probablement amorçable, approchez-la avec une extrême prudence!), Ou vivez simplement avec des traces de pile "pthread_cond_wait".

Answer 2

qui ressemble à une trace de la pile corrompue me

par exemple:

#9 0x0000000000000000 in ??() 

Il ne devrait pas être le code à NULL

Answer 3

En général, la synchronisation est nécessaire lorsque plusieurs threads partagent un seul Ressource. Dans ce cas, lorsque vous interrompez le programme, vous verrez qu'un seul thread est en cours d'exécution (c'est-à-dire, accéder à la ressource) et que d'autres threads sont en attente au sein de pthread_cond_wait().

Donc, je ne pense pas pthread_cond_wait() lui-même est problématique.

Si votre programme se bloque avec un blocage ou si les performances ne sont pas à l'échelle, cela peut être dû à pthread_cond_wait().