CODEWITHSUNDEEP
cmemory-leaksvalgrind
Elena Guidi
Elena Guidi

Reputation: 41

pthread_created followed by pthread_join valgrind possible loss c

I've a problem with valgrind errors about loss memory. This is my code:

if((err = pthread_create(&handlert, NULL, &handler, NULL)) != 0) perror(..)

if((err = pthread_create(&mastert , NULL, &createmaster, NULL)) != 0) perror(..)

for(int i = 0; i < THREADSINPOOL; i++) {
    if((err = pthread_create(&(f[i]), NULL, &createpool, NULL)) != 0) perror(..)
}

if((err = pthread_join(handlert,(void*) &sRet[1])) != 0) perror(..)

if((err = pthread_join(mastert,(void*) &lRet[1])) != 0) perror(..)

for(int i = 0; i < THREADSINPOOL; i++) {
    if((err = pthread_join(f[i], (void*) &wRet[i])) != 0) perror(..)
}
return 0;

I've a join for each thread and I'm checking the result but valgrind still say:

==21610== 560 bytes in 1 blocks are possibly lost in loss record 8 of 12
==21610==    at 0x4C2CC90: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21610==    by 0x4012E44: allocate_dtv (dl-tls.c:296)
==21610==    by 0x4012E44: _dl_allocate_tls (dl-tls.c:460)
==21610==    by 0x4E3FCC0: allocate_stack (allocatestack.c:589)
==21610==    by 0x4E3FCC0: pthread_create@@GLIBC_2.2.5 (pthread_create.c:495)
==21610==    by 0x401B3B: main (myfile.c:85)

(Same error for every pthread create, changing only the line of the code) Thank you in advance!

EDIT: flags in compilation: --leak-check=full -std=c99 -Wall -pedantic -g -DMAKE_VALGRIND_HAPPY There is only this error (don't look like a consequence of previous errors)

Upvotes: 3

Views: 863

Answers (1)

cnicutar
cnicutar

Reputation: 182649

I don't think this is a real leak, or if it is it's most likely in low-level code. And it's debatable if it should be considered a leak or an eager optimization.

See http://sourceware.org/ml/glibc-bugs/2007-04/msg00036.html:

It is not a real leak. As far as i know The buffer allocated at pthread_create() is used to extend the stack of threads. If you pthread_join() and pthread_create() again The old position in the stack will be used by the new one.

This is also alluded to in https://stackoverflow.com/a/17642468/714501

some implementations of POSIX threads (I'm guessing you're using glibc/NPTL) cache and reuse thread resources rather than freeing them fully.

I think for this case you could install a valgrind suppression:

http://valgrind.org/docs/manual/mc-manual.html#mc-manual.suppfiles

Upvotes: 3

Related Questions