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 0000000000624000 8 8 8 rw--- xl 0000000000626000 4 4 4 rw--- [ anon ] 0000000000841000 288 240 240 rw--- [ anon ] 00007f9ca48b4000 23852 14464 14464 rw--- [ anon ] 00007f9ca8000000 132 8 8 rw--- [ anon ] 00007f9ca8021000 65404 0 0 ----- [ anon ] 00007f9cae639000 104 0 0 r-x-- libz.so.1.2.8 << snip >> 00007ffff736e000 132 104 104 rw--- [ stack ] 00007ffff73f4000 8 8 0 r-x-- [ anon ] 00007ffff73f6000 8 0 0 r---- [ anon ] ffffffffff600000 4 0 0 r-x-- [ anon ] ---------------- ------- ------- ------- total kB 119812 17124 15052 After init 6 within the VM: 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 144 0 r-x-- xl 0000000000623000 4 4 4 r---- xl 0000000000624000 8 8 8 rw--- xl 0000000000626000 4 4 4 rw--- [ anon ] 0000000000841000 288 288 288 rw--- [ anon ] 0000000000889000 2292 2292 2292 rw--- [ anon ] 00007f9ca3169000 23852 14464 14464 rw--- [ anon ] 00007f9ca48b4000 23852 14464 14464 rw--- [ anon ] 00007f9ca8000000 132 8 8 rw--- [ anon ] 00007f9ca8021000 65404 0 0 ----- [ anon ] 00007f9cae639000 104 88 0 r-x-- libz.so.1.2.8 << snip >> ---------------- ------- ------- ------- total kB 145964 34620 31864 another init 6: 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 144 0 r-x-- xl 0000000000623000 4 4 4 r---- xl 0000000000624000 8 8 8 rw--- xl 0000000000626000 4 4 4 rw--- [ anon ] 0000000000841000 288 288 288 rw--- [ anon ] 0000000000889000 2292 2292 2292 rw--- [ anon ] 00007f9ca1a1e000 23852 14464 14464 rw--- [ anon ] 00007f9ca3169000 23852 14464 14464 rw--- [ anon ] 00007f9ca48b4000 23852 14464 14464 rw--- [ anon ] << snip >> ---------------- ------- ------- ------- total kB 169816 49084 46328 --------------- For my older domUs running i386 wheezy, the initial size of xl is hugely smaller: # pmap -x 10380 10380: /usr/lib/xen-4.4/bin/xl create aptcache_deb70.cfg Address Kbytes RSS Dirty Mode Mapping 0000000000400000 144 128 0 r-x-- xl 0000000000623000 4 4 4 r---- xl 0000000000624000 8 8 8 rw--- xl 0000000000626000 4 4 4 rw--- [ anon ] 00000000015e3000 132 132 132 rw--- [ anon ] 00007fb484000000 132 8 8 rw--- [ anon ] 00007fb484021000 65404 0 0 ----- [ anon ] 00007fb4893d4000 104 0 0 r-x-- libz.so.1.2.8 << snip >> ---------------- ------- ------- ------- total kB 95808 2604 488 After first init 6: # pmap -x 10380 10380: /usr/lib/xen-4.4/bin/xl create aptcache_deb70.cfg Address Kbytes RSS Dirty Mode Mapping 0000000000400000 144 144 0 r-x-- xl 0000000000623000 4 4 4 r---- xl 0000000000624000 8 8 8 rw--- xl 0000000000626000 4 4 4 rw--- [ anon ] 00000000015e3000 132 132 132 rw--- [ anon ] 0000000001604000 5840 5780 5780 rw--- [ anon ] 00007fb484000000 132 8 8 rw--- [ anon ] 00007fb484021000 65404 0 0 ----- [ anon ] 00007fb4893d4000 104 100 0 r-x-- libz.so.1.2.8 << snip >> ---------------- ------- ------- ------- total kB 101656 8792 6276 And subsequent reboots don't make it grow any more.
Ian Campbell
2014-Nov-06 12:14 UTC
[Pkg-xen-devel] Bug#767295: Bug#767295: xl: apparent memory leak
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: strdup (strdup.c:43) ==5722== by 0x405F38E: libxl__device_disk_local_initiate_attach (libxl.c:2681) ==5722== by 0x408D2A6: libxl__bootloader_run (libxl_bootloader.c:385) ==5722== by 0x406B50C: initiate_domain_create (libxl_create.c:807) ==5722== by 0x406B50C: do_domain_create (libxl_create.c:1354) ==5722== by 0x406B6AF: libxl_domain_create_new (libxl_create.c:1377) ==5722== by 0x8056182: create_domain (xl_cmdimpl.c:2254) ==5722== by 0x8059F27: main_create (xl_cmdimpl.c:4407) ==5722== by 0x804E119: main (xl.c:360) ==5722== ==5722== 28 bytes in 1 blocks are definitely lost in loss record 39 of 72 ==5722== at 0x4026B2D: malloc (vg_replace_malloc.c:299) ==5722== by 0x4279EBB: read_message (xs.c:1143) ==5722== by 0x427A89B: read_thread (xs.c:1219) ==5722== by 0x40E7953: start_thread (pthread_create.c:304) ==5722== by 0x41CF95D: clone (clone.S:130) And the bootloader one appears to increase with each reboot. FTR I did: valgrind --leak-check=full xl cr -F /etc/xen/d32-1 (-F runs xl in the foreground, so this won't return to a prompt). Then in another window: xl reboot d32-1 (equivalent to running init 6). Ian.
Ian Campbell
2014-Nov-06 14:12 UTC
[Pkg-xen-devel] Bug#767295: Bug#767295: Bug#767295: xl: apparent memory leak
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 of 72 > ==5722== at 0x4026B2D: malloc (vg_replace_malloc.c:299) > ==5722== by 0x41739FF: strdup (strdup.c:43) > ==5722== by 0x405F38E: libxl__device_disk_local_initiate_attach (libxl.c:2681) > ==5722== by 0x408D2A6: libxl__bootloader_run (libxl_bootloader.c:385) > ==5722== by 0x406B50C: initiate_domain_create (libxl_create.c:807) > ==5722== by 0x406B50C: do_domain_create (libxl_create.c:1354) > ==5722== by 0x406B6AF: libxl_domain_create_new (libxl_create.c:1377) > ==5722== by 0x8056182: create_domain (xl_cmdimpl.c:2254) > ==5722== by 0x8059F27: main_create (xl_cmdimpl.c:4407) > ==5722== by 0x804E119: main (xl.c:360) > ==5722== > ==5722== 28 bytes in 1 blocks are definitely lost in loss record 39 of 72 > ==5722== at 0x4026B2D: malloc (vg_replace_malloc.c:299) > ==5722== by 0x4279EBB: read_message (xs.c:1143) > ==5722== by 0x427A89B: read_thread (xs.c:1219) > ==5722== by 0x40E7953: start_thread (pthread_create.c:304) > ==5722== by 0x41CF95D: clone (clone.S:130)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.
Debian Bug Tracking System
2014-Nov-27 21:24 UTC
[Pkg-xen-devel] Bug#767295: marked as done (xl: apparent memory leak)
Your message dated Thu, 27 Nov 2014 21:24:27 +0000 with message-id <E1Xu6Y7-00053h-N3 at franck.debian.org> and subject line Bug#767295: fixed in xen 4.4.1-4 has caused the Debian Bug report #767295, regarding xl: apparent memory leak to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner at bugs.debian.org immediately.) -- 767295: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767295 Debian Bug Tracking System Contact owner at bugs.debian.org with problems -------------- next part -------------- An embedded message was scrubbed... From: Gedalya <gedalya at gedalya.net> Subject: xl: apparent memory leak Date: Wed, 29 Oct 2014 17:36:39 -0400 Size: 6573 URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20141127/8137c268/attachment-0002.mht> -------------- next part -------------- An embedded message was scrubbed... From: Bastian Blank <waldi at debian.org> Subject: Bug#767295: fixed in xen 4.4.1-4 Date: Thu, 27 Nov 2014 21:24:27 +0000 Size: 7948 URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20141127/8137c268/attachment-0003.mht>
Debian Bug Tracking System
2014-Nov-30 19:51 UTC
[Pkg-xen-devel] Bug#767295: marked as done (xl: apparent memory leak)
Your message dated Sun, 30 Nov 2014 19:49:21 +0000 with message-id <E1XvAUj-0004CL-8G at franck.debian.org> and subject line Bug#767295: fixed in xen 4.4.1-5 has caused the Debian Bug report #767295, regarding xl: apparent memory leak to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner at bugs.debian.org immediately.) -- 767295: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767295 Debian Bug Tracking System Contact owner at bugs.debian.org with problems -------------- next part -------------- An embedded message was scrubbed... From: Gedalya <gedalya at gedalya.net> Subject: xl: apparent memory leak Date: Wed, 29 Oct 2014 17:36:39 -0400 Size: 6573 URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20141130/cfb673ab/attachment-0002.mht> -------------- next part -------------- An embedded message was scrubbed... From: Bastian Blank <waldi at debian.org> Subject: Bug#767295: fixed in xen 4.4.1-5 Date: Sun, 30 Nov 2014 19:49:21 +0000 Size: 7488 URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20141130/cfb673ab/attachment-0003.mht>
Reasonably Related Threads
- Bug#767295: [PATCH for-4.5 v2] libxc: don't leak buffer containing the uncompressed PV kernel
- Bug#767295: [PATCH for-4.5 v2] libxc: don't leak buffer containing the uncompressed PV kernel
- Bug#767295: Bug#767295: Bug#767295: xl: apparent memory leak
- Bug#767295: Bug#767295: Bug#767295: xl: apparent memory leak
- Bug#767295: Bug#767295: Bug#767295: xl: apparent memory leak