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

[Steven Haigh <netwiz@crc.id.au>]

[-- Attachment #1.1: Type: text/plain, Size: 3579 bytes --]

On 26/03/14 19:57, Ian Campbell wrote:
> 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>
>         

I am using the qemu-xen-traditional that comes with xen-4.2.3.tar.gz

There are no patches on top of this apart from:
$ cat qemu-xen.tradonly.patch
--- xen-4.2.0/tools/Makefile.orig       2012-05-27 20:29:17.372660785 +0100
+++ xen-4.2.0/tools/Makefile    2012-05-27 20:38:24.066826167 +0100
@@ -35,7 +35,7 @@
 # do not recurse in to a dir we are about to delete
 ifneq "$(MAKECMDGOALS)" "distclean"
 SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir
-SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-dir
+#SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-dir
 endif

 SUBDIRS-y += xenpmd


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

Will see what I can get the reporter to discover with this...

--
Steven Haigh

Email: netwiz@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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