Detached pthreads and memory leak

I checked the program with slight modifications on windows using cygwin, and memory consumption was steady. So it must be a qt issue; the pthread library on cygwin works fine without leaking.

#include <pthread.h>#include <stdio.h>#include <unistd.h>void *threadFunc( void *arg ){printf("#");pthread_exit(NULL);}int main(){pthread_t thread;pthread_attr_t attr;int idx;while(1)    {    printf("\nStarting threads...\n");    for(idx=0;idx<100;idx++)        {        pthread_attr_init(&attr);        pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);        pthread_create( &thread, &attr, &threadFunc, NULL);        pthread_attr_destroy ( &attr );        }    printf("\nSleeping 10 seconds...\n");    //Sleep(10000);sleep(10);    }}

Compiler optimizations or the OS it self can decide to do loop unrolling. That is your for loop has a constant bound (100 here). Since there is no explicit synchronization to prevent it, a newly created, detached thread can die and have its thread ID reassigned to another new thread before its creator returns from pthread_create() due to this unrolling. The next iteration is already started before the thread was actually destroyed.

This also explains why your added slight delay has less issues; one iteration takes longer and hence the thread functions can actually finish in more cases and hence the threads are actually terminated most of the time.

A possible fix would be to disable compiler optimizations, or add synchronization; that is, you check whether the thread still exist, at the end of the code, if it does you'll have to wait for the function to finish.A more tricky way would be to use mutexes; you let the thread claim a resource at creation and by definition of PTHREAD_CREATE_DETACHED this resource is automatically released when the thread is exited, hence you can use try_lock to test whether the thread is actually finished. Note that I haven't tested this approach so I'm not actually sure whether PTHREAD_CREATE_DETACHED actually is working according to its definition...

Concept:

pthread_mutex_t mutex;void *threadFunc( void *arg ){  printf("#");  pthread_mutex_lock(&mutex);  pthread_exit(NULL);}for(int idx=0;idx<100;idx++){  pthread_attr_init(&attr);  pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);  pthread_create( &thread, &attr, &threadFunc, NULL);  pthread_attr_destroy ( &attr );  pthread_mutex_lock(&mutex); //will block untill "destroy" has released the mutex  pthread_mutex_unlock(&mutex);}

The delay can induce a large change in behavior because it gives the thread time to exit! Of course how your pthread library is implemented is also a factor here. I suspect it is using a 'free list' optimization.

If you create 1000 threads all at once, then the library allocates memory for them all before any significant number of those threads can exit.

If as in your second code sample you let the previous thread run and probably exit before you start a new thread, then your thread library can reuse that thread's allocated memory or data structures which it now knows are no longer needed and it is now probably holding in a free list just in case someone creates a thread again and it can efficiently recycle the memory.