I'm writing a program using the pthread library. When I run my program with the command valgrind --leak-check=full, I get the following errors description:
==11784==
==11784== **HEAP SUMMARY:**
==11784== in use at exit: 4,952 bytes in 18 blocks
==11784== total heap usage: 1,059 allocs, 1,041 frees, 51,864 bytes allocated
==11784==
==11784== **288 bytes** in 1 blocks are possibly lost in loss record 2 of 3
==11784== at 0x4C2380C: calloc (vg_replace_malloc.c:467)
==11784== by 0x4010D2E: _dl_allocate_tls (dl-tls.c:300)
==11784== by 0x55DC218: **pthread_create**@@GLIBC_2.2.5 (allocatestack.c:570)
==11784== by 0x401BC0: initdevice(char*) (in /a/fr-01/vol/home/stud/lim/workspace /Ex3/l)
==11784== by 0x406D05: main (in /a/fr-01/vol/home/stud/lim/workspace/Ex3/l)
==11784==
==11784== **4,608 bytes** in 16 blocks are possibly lost in loss record 3 of 3
==11784== at 0x4C2380C: calloc (vg_replace_malloc.c:467)
==11784== by 0x4010D2E: _dl_allocate_tls (dl-tls.c:300)
==11784== by 0x55DC218: **pthread_create**@@GLIBC_2.2.5 (allocatestack.c:570)
==11784== by 0x40268F: write2device(char*, int) (in /a/fr-01/vol/home/stud/lim/workspace/Ex3/l)
==11784== by 0x406D7B: main (in /a/fr-01/vol/home/stud/lim/workspace/Ex3/l)
==11784==
==11784== **LEAK SUMMARY:**
==11784== definitely lost: 0 bytes in 0 blocks
==11784== indirectly lost: 0 bytes in 0 blocks
==11784== possibly lost: 4,896 bytes in 17 blocks
==11784== still reachable: 56 bytes in 1 blocks
==11784== suppressed: 0 bytes in 0 blocks
==11784== Reachable blocks (those to which a pointer was found) are not shown.
==11784== To see them, rerun with: --leak-check=full --show-reachable=yes
==11784==
==11784== For counts of detected and suppressed errors, rerun with: -v
==11784== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4)
Every time I call pthread_create, with a certain function - I call the function pthread_exit in the end of the function. So, after verifying this is not the problem, what could be the problem?
A thread's resources are not immediately released at termination, unless
the thread was created with the detach state attribute set to
PTHREAD_CREATE_DETACHED, or if pthread_detach is called for
its pthread_t.
An undetached thread will remain terminated state until its identifier is passed to pthread_join or pthread_detach.
To sum it up, you have three options:
- create your thread with detached attribute set(PTHREAD_CREATE_DETACHED attribute)
- Detach your thread after creation (by calling
pthread_detach), or - Join with the terminated threads to recycle them (by calling
pthread_join).
Hth.
when not working with joinable threads the exiting thread needs to call pthread_detach(pthread_self())
in order to release all its resources.
You can make the thread in detached state to avoid the memory leak if the thread should not be joined (or just expires on it's own).
To explicitly create a thread as joinable or detached, the attr argument in the pthread_create() routine is used. The typical 4 step process is:
- Declare a pthread attribute variable of the
pthread_attr_tdata type - Initialize the attribute variable with
pthread_attr_init() - Set the attribute detached status with
pthread_attr_setdetachstate() - When done, free library resources used by the attribute with
pthread_attr_destroy()
In addition to the correct answers given you by other users, I suggest you to read this:
Please note that the default pthread_create behavior is "joinable" NOT DETACHED. Therefore some OS resources would still remain in the process after pthread finished, which would result in zombie pthread and leads to increased VIRTUAL/resident memory usage.
The four solution @sehe mentioned would fix this problem.
However if you thread is a long-standing one, this might not be really needed. for example, if the pthread lives through the whole life of the process.
来源：https://stackoverflow.com/questions/5610677/valgrind-memory-leak-errors-when-using-pthread-create