Menu
I have run my code through valgrind with these results:
==4492== Memcheck, a memory error detector
==4492== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==4492== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==4492== Command: ./mem
==4492== Parent PID: 4455
==4492==
==4492==
==4492== HEAP SUMMARY:
==4492== in use at exit: 0 bytes in 0 blocks
==4492== total heap usage: 19,595,342 allocs, 19,595,342 frees, 27,194,270 bytes allocated ==4492==
==4492== All heap blocks were freed -- no leaks are possible
==4492==
==4492== For counts of detected and suppressed errors, rerun with: -v
==4492== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
However, while the code is running, I see a small, steady increase in the memory used by the program. How sure can I be with that result?
I run valgrind using:
valgrind --track-origins=yes --leak-check=yes
--tool=memcheck --read-var-info=yes --log-file=error.txt`
and I compile the program using the -g and the -march=core2 tags.
608
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.
In non-memory leak detection mode you pass through directly to malloc and free, and in memory leak detection mode you first log the alloc and free calls and then call through to malloc and free. When the program finishes you match up the allocations and frees, and you'll see where you're leaking memory.
possibly lost: heap-allocated memory that was never freed to which valgrind cannot be sure whether there is a pointer or not. still reachable: heap-allocated memory that was never freed to which the program still has a pointer at exit (typically this means a global variable points to it).
You need to distinguish between memory leaks (memory that was allocated, but you lost all references to) and memory hogs (memory that was allocated, that you keep references to, but forgot to deallocate).
The later one can not be detected by valgrind, since valgrind doesn't know you did not want to use it anymore.
To get some statistics about your programs memory usage, you can use the massif tool of valgrind, which will show you in more detail where your memory gets allocated. This might be helpful in finding memory hogs.
134
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
