On Thu, Oct 21, 2010 at 09:34:59AM -0400, Stefan Berger wrote:

I am wondering if someone could interpret the valgind output for memory leak check that I see when I look for memory leaks...

When a thread for creating a VM was spawned I see this output for example:

==15488== LEAK SUMMARY: ==15488== definitely lost: 9,133 bytes in 12 blocks ==15488== indirectly lost: 10,248 bytes in 5 blocks ==15488== possibly lost: 319,199 bytes in 2,887 blocks ==15488== still reachable: 4,635,633 bytes in 30,308 blocks ==15488== suppressed: 0 bytes in 0 blocks ==15488== Reachable blocks (those to which a pointer was found) are not shown. ==15488== To see them, rerun with: --leak-check=full --show-reachable=yes

The traces above it show some 'wild' paths into libraries. We may either not be using the libraries correctly or they have leaks themselves ...

Libvirt spawns quite a few child processes, so valgrind may be telling you about leaks in those, rather than leaks in libvirt.

When terminating the valgrind process by sending a -SIGTERM to it I then get this:

==15488== LEAK SUMMARY: ==15488== definitely lost: 0 bytes in 0 blocks ==15488== indirectly lost: 0 bytes in 0 blocks ==15488== possibly lost: 2,701 bytes in 25 blocks ==15488== still reachable: 543,655 bytes in 7,928 blocks ==15488== suppressed: 0 bytes in 0 blocks ==15488== Reachable blocks (those to which a pointer was found) are not shown. ==15488== To see them, rerun with: --leak-check=full --show-reachable=yes

So in the end is there no leak with 'defintely and indirectly' lost being '0'?

Actually other tests are not as favorable in the end:

==17333== LEAK SUMMARY: ==17333== definitely lost: 32 bytes in 1 blocks ==17333== indirectly lost: 1,449,440 bytes in 2,020 blocks ==17333== possibly lost: 1,007,275 bytes in 9,780 blocks ==17333== still reachable: 543,827 bytes in 7,933 blocks ==17333== suppressed: 0 bytes in 0 blocks ==17333== Reachable blocks (those to which a pointer was found) are not shown. ==17333== To see them, rerun with: --leak-check=full --show-reachable=yes

You should re-run with --leak-check=full which will let you see whether the reported leaks are coming from libvirt, or child processes run by libvirt, and give you stack traces showing where each leak is. Also, if you're tracing a libvirtd that you're running from the source tree, then you'll in fact be tracing a libtool wrapper script. So for in-source tree tracing make sure you run libtool --mode=execute valgrind --leak-check=full ./daemon/libvirtd if you want to avoid tracing all the libtool stuff Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|