pthread_cond_timedwait hanging with gdb

Question

I'm using pthread_cond_timedwait on a thread loop to execute at every X ms (unless it is waked first).

When I'm using gdb to debug it sometimes it the function never returns.

This forum post also have the same problem, but there is no solution.

Here's some code that reproduces the problem:

#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;
}

If I run it, it will run OK, and if I run in gdb it will also run OK.

I've narrowed down to these steps (I've named the program timedTest ):

1. Run the program;

2. While it runs attach gdb to it;

3. Execute continue on gdb;

4. The timedTest program never returns...;

Then, if I hit Ctrl+C on the terminal running gdb and run continue again, then the program will return.

I can probably use some other method to achieve what I want in this case, but I assume that it should be a solution to this problem.

EDIT:

Looks like this only happens in some machines, so maybe there's something to do with gcc / glibc / gdb / kernel versions...

Versions where this happens almost always:

$ 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

According to this forum post, this is a bug in the 2.6.38 kernel. I've made some tests with a 2.6.39 kernel and problem does not happen. Rolling back to the 2.6.38 it appears again.