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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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@xxxxxxxxxxx>
        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@xxxxxxxxx>
            Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
            Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
            
            Backport to qemu-xen-traditional.
            
            Signed-off-by: Matthew Daley <mattd@xxxxxxxxxxx>
            Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
        
> 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@xxxxxxxxx>
        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@xxxxxxxxx>
        
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.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel