You are not logged in.
Pages: 1
Hello. I have written a simple program that creates a linked list by calling malloc to allocate memory for the linked list pointers and the individual nodes. There are 23 nodes, and 1 linked list, so 24 allocations are made (and 24 are freed).
Valgrind, however, disagrees: its output states that the program in fact performs 25 allocations (and only 24 frees), with no memory lost, but with 568 bytes still reachable at program termination.
Here is the output from valgrind. I am assuming that this is characteristic behaviour, and many users already know what it is about(and can share without losing too much time).
HEAP SUMMARY:
==11403== in use at exit: 568 bytes in 1 blocks
==11403== total heap usage: 25 allocs, 24 frees, 1,136 bytes allocated
==11403==
==11403== Searching for pointers to 1 not-freed blocks
==11403== Checked 100,960 bytes
==11403==
==11403== 568 bytes in 1 blocks are still reachable in loss record 1 of 1
==11403== at 0x4C2519D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11403== by 0x4E8CE3A: ??? (in /lib/libc-2.12.1.so)
==11403== by 0x400AC8: main (hostd.c:131)
==11403==
==11403== LEAK SUMMARY:
==11403== definitely lost: 0 bytes in 0 blocks
==11403== indirectly lost: 0 bytes in 0 blocks
==11403== possibly lost: 0 bytes in 0 blocks
==11403== still reachable: 568 bytes in 1 blocks
==11403== suppressed: 0 bytes in 0 blocks
==11403==
==11403== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 7)
--11403--
--11403-- used_suppression: 4 U1004-ARM-_dl_relocate_object
--11403-- used_suppression: 3 glibc-2.5.x-on-SUSE-10.2-(PPC)-2a
==11403==
==11403== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 7)
Thank you in advance for any responses.
Last edited by dillesca (2010-11-28 10:46:40)
---Lenovo T510--Intel(R) Core(TM) i7 CPU M620@2.67GHz---x86_64---4GB RAM---NVIDIA NVS 3100---
---320GB Seagate Momentus 7200.4 Series Hard Drive---
----xfce4---2.6.36-ARCH---
Offline
The expected output when running valgrind is:
==12056== HEAP SUMMARY:
==12056== in use at exit: 0 bytes in 0 blocks
==12056== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==12056==
==12056== All heap blocks were freed -- no leaks are possibleTherefore, you didn't free everything you malloc'd. However, that backtrace makes it look like something you called is calling malloc() indirectly, in line 131 of main.c. One possible example is fopen(), which you should always match win an fclose(). If you post the code I'm sure I or someone else can point out what's missing.
Offline
Excellent. I was forgetting to call fclose(). I'm impressed. Thank you.
---Lenovo T510--Intel(R) Core(TM) i7 CPU M620@2.67GHz---x86_64---4GB RAM---NVIDIA NVS 3100---
---320GB Seagate Momentus 7200.4 Series Hard Drive---
----xfce4---2.6.36-ARCH---
Offline
Haha you're welcome. Don't forget to mark the thread as [SOLVED].
Offline
[Deleted by poster]
Last edited by dillesca (2010-11-28 11:20:48)
---Lenovo T510--Intel(R) Core(TM) i7 CPU M620@2.67GHz---x86_64---4GB RAM---NVIDIA NVS 3100---
---320GB Seagate Momentus 7200.4 Series Hard Drive---
----xfce4---2.6.36-ARCH---
Offline
Pages: 1