[libvirt] memory leaks...

[Daniel P. Berrange]

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 :|