similar to: Bug#767295: xl: apparent memory leak

On 11/20/2014 03:21 PM, Konrad Rzeszutek Wilk wrote: > On Thu, Nov 20, 2014 at 03:48:47PM +0000, Ian Campbell wrote: >> The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which >> is freed by xc_dom_release. However the various xc_try_*_decode routines (other >> than the gzip one) just use plain malloc/realloc and therefore the buffer ends >> up

On Thu, 2014-11-20 at 22:13 -0500, Gedalya wrote: > On 11/20/2014 03:21 PM, Konrad Rzeszutek Wilk wrote: > > On Thu, Nov 20, 2014 at 03:48:47PM +0000, Ian Campbell wrote: > >> The libxc xc_dom_* infrastructure uses a very simple malloc memory pool which > >> is freed by xc_dom_release. However the various xc_try_*_decode routines (other > >> than the gzip one)

On 11/06/2014 09:12 AM, Ian Campbell wrote: > I've posted a fix for this upstream: > http://lists.xen.org/archives/html/xen-devel/2014-11/msg00542.html > > I've requested that it go into the next 4.4.x release. I also plan to > backport it to the package regardless once it is accepted into the dev > branch. > > Ian. So I've tried building xen 4.4.1-3 with this

On Thu, 2014-11-06 at 12:14 +0000, Ian Campbell wrote: > On Wed, 2014-10-29 at 17:36 -0400, Gedalya wrote: > > When booting domU's running amd64 jessie, I notice some memory problems > > with xl. > > I ran it (actually, upstream staging-4.4) under valgrind and it reported > after a reboot: > > ==5722== 24 bytes in 1 blocks are definitely lost in loss record 35

On Wed, 2014-10-29 at 17:36 -0400, Gedalya wrote: > When booting domU's running amd64 jessie, I notice some memory problems > with xl. I ran it (actually, upstream staging-4.4) under valgrind and it reported after a reboot: ==5722== 24 bytes in 1 blocks are definitely lost in loss record 35 of 72 ==5722== at 0x4026B2D: malloc (vg_replace_malloc.c:299) ==5722== by 0x41739FF:

On Sat, 2014-11-08 at 08:32 -0500, Gedalya wrote: > On 11/08/2014 05:41 AM, Ian Campbell wrote: > > Please can you try running xl under valgrind, something similar to what > > I described earlier should work. > I guess it didn't find much.. Indeed not :-/ I managed to get a test box up and running, so I backported a couple of additional upstream patches to help valgrind

On 11/09/2014 07:02 AM, Ian Campbell wrote: > On Sat, 2014-11-08 at 08:32 -0500, Gedalya wrote: >> On 11/08/2014 05:41 AM, Ian Campbell wrote: >>> Please can you try running xl under valgrind, something similar to what >>> I described earlier should work. >> I guess it didn't find much.. > Indeed not :-/ > > I managed to get a test box up and running,

On 11/09/2014 07:18 AM, Gedalya wrote: > That memory block is just a bit larger than the size of the initrd in > the VM, could there be a connection? Nope. I changed the initrd to 2.6mb and that memory block is still exactly at 23852 / 14464 / 14464. Actually the process size is around 12 mb when pygrub is counting down to boot, then jumps up to 14+ mb

Package: xen-utils-4.4 Version: 4.4.1-3 When booting domU's running amd64 jessie, I notice some memory problems with xl. root at xen:~# pmap -x 4121 4121: /usr/lib/xen-4.4/bin/xl create --quiet --defconfig /etc/xen/auto/mail_deb80.cfg Address Kbytes RSS Dirty Mode Mapping 0000000000400000 144 128 0 r-x-- xl 0000000000623000 4 4 4 r---- xl

On Fri, 2014-11-07 at 21:32 -0500, Gedalya wrote: > On 11/06/2014 09:12 AM, Ian Campbell wrote: > > I've posted a fix for this upstream: > > http://lists.xen.org/archives/html/xen-devel/2014-11/msg00542.html > > > > I've requested that it go into the next 4.4.x release. I also plan to > > backport it to the package regardless once it is accepted into the

Changes since v1: - Fix a double-free bug introduced by v1, pointed out by Stefano where internal pointer was being passed back to caller from libxl_create_stubdom() 8<---------------------------------------------------------------------- Currently scratch variables allocated by libxl have the same lifetime as the context. While this is suitable for one off invocations of xl. It is not

Processing commands for control at bugs.debian.org: > severity 767295 important Bug #767295 [xen-utils-4.4] xl: apparent memory leak Severity set to 'important' from 'normal' > thanks Stopping processing here. Please contact me if you need assistance. -- 767295: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767295 Debian Bug Tracking System Contact owner at

2015-01-28 12:47 GMT+03:00 Kashyap Chamarthy <kchamart@redhat.com>: > I don't have immediate steps with `virt-manager` as I don't use it much > in my workflow. But if you have users who're comfortable with CLI, you > can import disk images into libvirt (and which will also be accessible > via `virt-manager`) tribvially: > > $ virt-install --name f21vm --ram

On Fri, 2014-11-21 at 15:25 -0500, Gedalya wrote: > On 11/21/2014 06:12 AM, Ian Campbell wrote: > > On Fri, 2014-11-21 at 11:03 +0000, Ian Campbell wrote: > >> http://man7.org/linux/man-pages/man3/mallopt.3.html also talks about > >> various dynamic thresholds for growing and shrinking the heap. My guess > >> is that we are bouncing up and down over some

On 11/08/2014 05:41 AM, Ian Campbell wrote: > Please can you try running xl under valgrind, something similar to what > I described earlier should work. I guess it didn't find much.. # valgrind --leak-check=full xl cr -F /etc/xen/auto/asterisk_deb80.cfg ==6736== Memcheck, a memory error detector ==6736== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==6736== Using

On Wed, Jan 28, 2015 at 02:32:12AM +0400, Vasiliy Tolstov wrote: > Hi. I need to get ability to download backups of kvm virtual machines > (raw images) to end users. Virtualbox users can import ovs images, > that i can create, but in case of linux and virt-manager - how users > can import images and simply run it? > I think about newbie linux users, that can install virt-manager

On Wed, Jan 28, 2015 at 01:57:28PM +0400, Vasiliy Tolstov wrote: > 2015-01-28 12:47 GMT+03:00 Kashyap Chamarthy <kchamart@redhat.com>: > > I don't have immediate steps with `virt-manager` as I don't use it much > > in my workflow. But if you have users who're comfortable with CLI, you > > can import disk images into libvirt (and which will also be accessible

Hi, List, I''m trying xl create a pv guest with qcow/qcow2 image, it always fails at libxl_device_disk_local_attach. #xl create pv_config_file libxl: error: libxl.c:1119:libxl_device_disk_local_attach: cannot locally attach a qdisk image if the format is not raw libxl: error: libxl_create.c:467:do_domain_create: failed to run bootloader: -3 disk configuration is: disk=[

On Fri, 2014-11-21 at 11:03 +0000, Ian Campbell wrote: > http://man7.org/linux/man-pages/man3/mallopt.3.html also talks about > various dynamic thresholds for growing and shrinking the heap. My guess > is that we are bouncing up and down over some threshold with every other > reboot. IOW I'm not overly concerned with this apparent bi-modality, so long as the amount isn't

On 11/21/2014 06:12 AM, Ian Campbell wrote: > On Fri, 2014-11-21 at 11:03 +0000, Ian Campbell wrote: >> http://man7.org/linux/man-pages/man3/mallopt.3.html also talks about >> various dynamic thresholds for growing and shrinking the heap. My guess >> is that we are bouncing up and down over some threshold with every other >> reboot. > IOW I'm not overly concerned