Pthread_cond_timedwait hanging with gdb

I use pthread_cond_timedwait in a thread loop to execute in every X ms (unless it woke up first).

When I use gdb to debug it, sometimes the function never returns.

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

Here is the 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 work fine, and if I run it in gdb, it will work fine too.

I narrowed down to these steps (I called the timedTest program):

  • Run the program;

  • While it launches attach gdb,

  • Run continue on gdb;

  • The timedTest program never returns ...;

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

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

EDIT:

It seems that this only happens on some machines, so maybe something is related to the versions of gcc / glibc / gdb / kernel ...

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 
+6
source share
1 answer

According to this forum post , this is a bug in the 2.6.38 kernel . I conducted several tests with the 2.6.39 kernel, and the problem does not occur. Returning to 2.6.38, he reappears.

+4
source

Source: https://habr.com/ru/post/890193/


All Articles