Menu
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?
596
Valgrind Memcheck is a tool that detects memory leaks and memory errors. Some of the most difficult C bugs come from mismanagement of memory: allocating the wrong size, using an uninitialized pointer, accessing memory after it was freed, overrunning a buffer, and so on.
Yes, there are false positives with Valgrind, that's why it has suppression files for particular glibc and gcc versions, for example. The false positives may arise if you are using older valgrind with newer gcc and glibc, i.e., valgrind 3.3 with glibc 2.9.
To run Valgrind, pass the executable as an argument (along with any parameters to the program). The flags are, in short: --leak-check=full : "each individual leak will be shown in detail" --show-leak-kinds=all : Show all of "definite, indirect, possible, reachable" leak kinds in the "full" report.
Therefore, Valgrind allows you to selectively suppress errors, by recording them in a suppressions file which is read when Valgrind starts up. The build mechanism selects default suppressions which give reasonable behaviour for the OS and libraries detected on your machine.
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:
pthread_detach), orpthread_join).Hth.
98
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
