Re: Possible memory leak in qemu-dm (qemu-dm swapping 20GB+, adding 2gb+ per day)

[Ian Campbell <Ian.Campbell@citrix.com>]

On Wed, 2014-03-26 at 16:23 +1100, Steven Haigh wrote:
> Valgrind log available here:
> http://xen.crc.id.au/bugs/view.php?id=25

Thanks.

Before we go any further, can you confirm that you have this commit in
your qemu-xen-traditional tree:
        commit 96b58a44756a8821c108358439b0f2c06e531159
        Author: Matthew Daley <mattd@bugfuzz.com>
        Date:   Wed Dec 4 15:16:18 2013 +1300
        
            xen_disk: fix memory leak
            
            On ioreq_release the full ioreq was memset to 0, losing all the data
            and memory allocations inside the QEMUIOVector, which leads to a
            memory leak. Create a new function to specifically reset ioreq.
            
            Reported-by: Maik Wessler <maik.wessler@yahoo.com>
            Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
            Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
            
            Backport to qemu-xen-traditional.
            
            Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
            Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
        
> Do you have any further suggestions / ideas based on this?

Unfortunately the qemu-dm binary seems to have been stripped, which
removes much of the useful info from the traces. Please can you make
sure you have the following commit to the qemu-xen-traditional tree:
        commit 18a08a23da88863435d56a0b14ff72013ef3b003
        Author: Olaf Hering <olaf@aepfle.de>
        Date:   Tue Oct 15 11:42:26 2013 +0200
        
            qemu-traditional: do not strip binaries during make install
            
            It is wrong to strip code during make install, unless explicit
            requested. Introduce a new variable INSTALL_PROG and use it along with
            an optional STRIP_OPT where currently install -s -m 755 is used.
            This is what upstream qemu offers in version 1.6.
            
            Signed-off-by: Olaf Hering <olaf@aepfle.de>
        
If you are packaging this as RPM I guess you will also want the
accompanying debuginfo RPM installed too, since RPM will have done magic
with the unstripped binary.

Adding --leak-check=full and/or --track-origins=yes to the valgrind
options might also be helpful.

The most plausible candidate for a leak would seem to be "Syscall param
munmap(length) contains uninitialised byte(s)", but that might just be
down to "Warning: noted but unhandled ioctl 0x84501 with no
size/direction hints" on the corresponding mmap call. Hopefully with
debugging symbols things will become clearer.

Thanks,

Ian.