Not deallocating properly threads in C

user_7366255 0
Viewed 868

I'm doing a program in C that use threads that I will never know when they finish, so I'm using pthread_detach() to deallocate that memory, right?

Here's the code: 

pthread_t thread_id_Gruder, thread_id_Tavish;

estado_threadGruder = pthread_create(&thread_id_Gruder,NULL,SERVER_McGruderDedicado,&td_Gruder);

estado_threadTavish = pthread_create(&thread_id_Tavish,NULL,SERVER_McTavishDedicado,&td_Tavish);

if (estado_threadGruder != 0 || estado_threadTavish != 0) {
            if (estado_threadGruder != 0) MSSG_error(THREAD_ERROR, "McGruder");
            else MSSG_error(THREAD_ERROR, "McTavish");
            raise(SIGINT);
            pause();
}
pthread_detach(thread_id_Gruder);
pthread_detach(thread_id_Tavish);

But when I use valgrind to check memory leaks I found this output:

HEAP SUMMARY:
==19426==     in use at exit: 544 bytes in 2 blocks
==19426==   total heap usage: 15 allocs, 13 frees, 628 bytes allocated
==19426== 
==19426== Thread 1:
==19426== 272 bytes in 1 blocks are possibly lost in loss record 1 of 2
==19426==    at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19426==    by 0x40134A6: allocate_dtv (dl-tls.c:286)
==19426==    by 0x40134A6: _dl_allocate_tls (dl-tls.c:530)
==19426==    by 0x4E44227: allocate_stack (allocatestack.c:627)
==19426==    by 0x4E44227: pthread_create@@GLIBC_2.2.5 (pthread_create.c:644)
==19426==    by 0x1097AA: main (in /users/home/alumnes/LS//PRACTICA/Lionel-S/Lionel)
==19426== 
==19426== 272 bytes in 1 blocks are possibly lost in loss record 2 of 2
==19426==    at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19426==    by 0x40134A6: allocate_dtv (dl-tls.c:286)
==19426==    by 0x40134A6: _dl_allocate_tls (dl-tls.c:530)
==19426==    by 0x4E44227: allocate_stack (allocatestack.c:627)
==19426==    by 0x4E44227: pthread_create@@GLIBC_2.2.5 (pthread_create.c:644)
==19426==    by 0x1097CC: main (in /users/home/alumnes/LS//PRACTICA/Lionel-S/Lionel)
==19426== 
==19426== LEAK SUMMARY:
==19426==    definitely lost: 0 bytes in 0 blocks
==19426==    indirectly lost: 0 bytes in 0 blocks
==19426==      possibly lost: 544 bytes in 2 blocks
==19426==    still reachable: 0 bytes in 0 blocks
==19426==         suppressed: 0 bytes in 0 blocks
==19426== 
==19426== For counts of detected and suppressed errors, rerun with: -v
==19426== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)

I tried to run the code without the phtread_detach() function but valgrind shows the same memory leak, so I'm assuming I don't detach properly...

Am I detaching correctly the threads or maybe the problem is inside my threads?

Thanks.

multithreading valgrind c
1 Answers

The problem is most probably your threads. Even if you haven't used any malloc inside them.

Here's what happens, when you create a thread using pthread_create, the library allocates a bunch of things for the correct operation of the thread, and starts running it. Normally, these things are only freed when these threads are joined using pthread_join. However, in some cases there is no point in your code where you want to sync threads, and simply want them to be gone when they are done. That's why there is pthread_detach. A detached thread will clear itself up as soon as it's function returns. Notice, when they return.

If your threads have not finished when the program finishes, your main function will end ok, but your threads are still running. Since they have not yet returned, they still have not been cleaned up.

If you intend for these threads to run until the program is finished, or want to wait for them no finish at the program end, then you do have a point you want to synchronize them(the end of the program) and pthread_detach might not be the way to go.

If your threads have infinite loops, I recommend making a variable should_Terminate which starts as 0, and make your loops in the threads break if its value is 1. Then you set it to 1 when you want to terminate your program, and use pthread_join to wait for the threads to conclude their work gracefully.

If they don't have infinite loops, and will certainly return at some point, just joining them at the program end is enough.

user_62535270
Related