pthread_cond_timedwait colgado con gdb

Question

Estoy usando pthread_cond_timedwait en un bucle de hilo para ejecutar en cada X ms (a menos que se active primero).

Cuando estoy usando gdb para depurarlo a veces la función nunca vuelve.

This forum post también tienen el mismo problema, pero no hay solución.

Aquí hay un código que reproduce el problema:

#include <errno.h> 
#include <pthread.h> 
#include <stdio.h> 
#include <unistd.h> 

static pthread_cond_t s_cond = PTHREAD_COND_INITIALIZER; 
static pthread_mutex_t s_mutex = PTHREAD_MUTEX_INITIALIZER; 

int main(int argc, char **argv) 
{ 
    int rc = 0; 
    struct timespec curts = { 0 }; /* transformed timeout value */ 

    clock_gettime(CLOCK_REALTIME, &curts); 
    curts.tv_sec += 10; /* Add 10 seconds to current time*/ 

    pthread_mutex_lock(&s_mutex); 

    printf("pthread_cond_timedwait\n"); 
    rc = pthread_cond_timedwait(&s_cond, &s_mutex, &curts); 
    if (rc == ETIMEDOUT) 
    { 
     printf("Timer expired \n"); 
    } 

    pthread_mutex_unlock(&s_mutex); 

    return 1; 
} 

Si lo ejecuto, se ejecutará bien, y si me quedo en GDB También puede funcionar bien.

he reducido a estos pasos (He nombrado el programa timedTest):

1. Ejecutar el programa;

2. Mientras se ejecuta adjuntar gdb a ella;

3. Ejecute continue en gdb;

4. El programa timedTest nunca devuelve ...;

Entonces, si golpeo Ctrl+C en el GDB correr terminal y ejecute continue de nuevo, a continuación, el programa volverá.

Probablemente pueda utilizar algún otro método para lograr lo que quiero en este caso, pero supongo que debería ser una solución a este problema.

EDIT:

Parece que esto sólo ocurre en algunas máquinas, por lo que tal vez hay algo que ver con gcc/glibc/GDB versiones/kernel ...

versiones en las que esto sucede casi siempre:

$ ldd --version 
ldd (Ubuntu EGLIBC 2.13-0ubuntu13) 2.13 

$ gcc --version 
gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2 

$ gdb --version 
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2 

$ uname -a 
Linux geovani 2.6.38-8-generic-pae #42-Ubuntu SMP Mon Apr 11 05:17:09 UTC 2011 i686 i686 i386 GNU/Linux 

Answer 1

Según this forum post, esto es un error en el kernel 2.6.38. He hecho algunas pruebas con un núcleo 2.6.39 y el problema no ocurre. Volviendo al 2.6.38 aparece de nuevo.