Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Can valgrind output partial reports without having to quit the profiled application?

Tags:

valgrind

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?

like image 645
Fred Avatar asked Mar 15 '12 13:03

Fred


People also ask

What are the problems with Valgrind?

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.

How does Valgrind work internally?

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.

What does Valgrind return?

When set to the default value (zero), the return value from Valgrind will always be the return value of the process being simulated.


1 Answers

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.

like image 176
Mat Avatar answered Oct 12 '22 20:10

Mat