[libvirt] memory leaks...

[Dave Allan]

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 ...
> 
> 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
> 
>   Stefan

I noticed a while back that libpciaccess uses an internal lookup table
which it never frees, so it is reported, correctly, as a memory leak.
This behavior is apparently by design, and the table is bounded by the
number of different PCI device vendors in the system, so it hasn't
caused us any problems other than showing up in valgrind output.

Dave