All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>, Sunguodong <sunguodong@huawei.com>
Cc: Fanhenglong <fanhenglong@huawei.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Huangpeng (Peter)" <peter.huangpeng@huawei.com>,
	"Hanweidong	(Randy)" <hanweidong@huawei.com>
Subject: Re: Found memory leak in libxenstore
Date: Mon, 7 Sep 2015 11:46:32 +0100	[thread overview]
Message-ID: <1441622792.25589.76.camel@citrix.com> (raw)
In-Reply-To: <20150907103748.GE6436@zion.uk.xensource.com>

On Mon, 2015-09-07 at 11:37 +0100, Wei Liu wrote:
> I only had a brief look at this.
> 
> On Mon, Sep 07, 2015 at 09:52:08AM +0000, Sunguodong wrote:
> > Hi,
> > I found this memory leak on xen-4.5.0:
> > linux-byXjTX:~ # virsh version
> > Compiled against library: libvirt 1.2.17
> > Using library: libvirt 1.2.17
> > Using API: Xen 1.2.17
> > Running hypervisor: Xen 4.5.0
> > 
> > Steps to produce this leak:
> > 
> > 1.       Start a vm, win7_64_2U_vhd, for example.
> > 
> > 2.       Stop libvirtd and start it with valgrind, using the following 
> > command:
> > 
> > valgrind --tool=memcheck --log-file=xs.log --leak-check=full --show
> > -reachable=yes --track-origins=yes --trace-children=yes --verbose 
> > libvirtd -d -l
> > 
> > 3.       Wait until libvirtd started, then reboot the vm:
> > 
> > virsh reboot win7_64_2U_vhd
> > 
> > 4.       After vm restarted, kill valgind with signal 3:
> > 
> > kill -3 27483 (27483 is the pid of valgrind)
> > 
> > 5.       Open xs.log, search 'definitely', we will always find this 
> > leak:
> > 
> > ==28989== 40 bytes in 1 blocks are definitely lost in loss record 327 
> > of 585
> > 
> > ==28989==    at 0x4C27B9B: malloc (vg_replace_malloc.c:263)
> > 
> > ==28989==    by 0x7EBD618: read_message (xs.c:1146)
> > 
> > ==28989==    by 0x7EBE8C6: read_thread (xs.c:1222)
> > 
> > ==28989==    by 0x74F8805: start_thread (in /lib64/libpthread
> > -2.11.3.so)
> > 
> > ==28989==    by 0x77EC66C: clone (in /lib64/libc-2.11.3.so)
> > 
> > When we reboot vm twice, this leak would happen twice either. Could 
> > anyone verify this and fix it?
> 
> Those messages are freed after the connection is closed. Are you sure
> they are still there after you close the connection?

It seems like libvirtd would be killed ungraciously by killing valgrind in
step 4 above, so it would never close down these connections and cleanup
the memory used by them.

A better test would be to send libvirtd whatever signal causes it to exit
gracefully.

Ian.

      parent reply	other threads:[~2015-09-07 10:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-07  9:52 Found memory leak in libxenstore Sunguodong
2015-09-07 10:37 ` Wei Liu
2015-09-07 10:40   ` Wei Liu
2015-09-07 10:46   ` Ian Campbell [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1441622792.25589.76.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=fanhenglong@huawei.com \
    --cc=hanweidong@huawei.com \
    --cc=peter.huangpeng@huawei.com \
    --cc=sunguodong@huawei.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.