I want to check a long running process for memory leaks with valgrind. I suspect the memory leak I'm after might happen only after several hours of execution. I can run the app under valgrind and get the valgrind log just fine, but doing so means I have to quit the application and start it again anew for a new valgrind session for which I would still have to wait several hours. Is it possible to keep valgrind and the app running and still get valgrind's (partial) data at any point during execution?
Valgrind reports two types of issues: memory errors and memory leaks. When a program dynamically allocates memory and forgets to later free it, it creates a leak. A memory leak generally won't cause a program to misbehave, crash, or give wrong answers, and is not an urgent situation.
Valgrind works by doing a just-in-time (JIT) translation of the input program into an equivalent version that has additional checking. For the memcheck tool, this means it literally looks at the x86 code in the executable, and detects what instructions represent memory accesses.
When set to the default value (zero), the return value from Valgrind will always be the return value of the process being simulated.
You can do that by using the Valgrind gdbserver and GDB.
In short, you start your program with valgrind as usual, but with the --vgdb=yes
switch:
$ valgrind --tool=memcheck --vgdb=yes ./a.out
In another session, you start gdb on the same executable, and connect to valgrind. You can then issue valgrind commands:
$ gdb ./a.out
...
(gdb) target remote | vgdb
....
(gdb) monitor leak_check full reachable any
==8677== 32 bytes in 1 blocks are definitely lost in loss record 1 of 2
==8677== at 0x4C28E3D: malloc (vg_replace_malloc.c:263)
==8677== by 0x400591: foo (in /home/me/tmp/a.out)
==8677== by 0x4005A7: main (in /home/me/tmp/a.out)
==8677==
==8677== 32 bytes in 1 blocks are definitely lost in loss record 2 of 2
==8677== at 0x4C28E3D: malloc (vg_replace_malloc.c:263)
==8677== by 0x400591: foo (in /home/me/tmp/a.out)
==8677== by 0x4005AC: main (in /home/me/tmp/a.out)
==8677==
==8677== LEAK SUMMARY:
==8677== definitely lost: 64 bytes in 2 blocks
==8677== indirectly lost: 0 bytes in 0 blocks
==8677== possibly lost: 0 bytes in 0 blocks
==8677== still reachable: 0 bytes in 0 blocks
==8677== suppressed: 0 bytes in 0 blocks
==8677==
(gdb)
See the manual for a list of commands, here for memcheck.
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