backtrace gdb y pthread_cond_wait ()

Question

Esto es en una máquina Redhat EL5 w / a kernel 2.6.18-164.2.1.el5 x86_64 usando gcc 4.1.2 y gdb 7.0.

Cuando ejecuto mi aplicación con gdb y romper en mientras se está ejecutando, varios de mis hilos mostrar la siguiente pila de llamadas cuando hago una traza inversa:

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

¿Es esto un síntoma de un problema común?
¿Hay un problema conocido con la visualización de la pila de llamadas a la espera de una condición?

Answer 1

El problema es que pthread_cond_wait está escrito en el ensamblaje codificadas a mano, y al parecer no tiene descriptor de desenrollado adecuada (requerido en x86_64 para desenrollar la pila) en su acumulación de glibc. Este problema se puede recientemente se han fijado aquí .

Se puede tratar de construir e instalar la última versión de glibc (NOTA: Si metes la pata de la instalación, la máquina es probable que no se podrá iniciar; enfoque con extrema precaución)., O simplemente vivir con "falsos" seguimientos de pila de pthread_cond_wait

Answer 2

Generalmente, se requiere sincronización cuando varios subprocesos comparten un solo recurso. En tal caso, cuando se interrumpe el programa, verá solamente 1 hilo está funcionando (es decir, el acceso a los recursos) y otros hilos se espera dentro de pthread_cond_wait().

Así que no creo pthread_cond_wait() sí es problemático.

Si el programa se bloquea con estancamiento o el rendimiento no escala, que podría ser causada por pthread_cond_wait().

Answer 3

Eso se parece a un seguimiento de pila corrupta me

por ejemplo:

#9  0x0000000000000000 in ?? ()

No debe haber código en NULL