[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Possible memory leak in qemu-dm (qemu-dm swapping 20GB+, adding 2gb+ per day)
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@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> > 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@xxxxxxxxx Web: https://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 Fax: (03) 8338 0299 Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |