From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH] tools: libxl: do not leak diskpath during local disk attach Date: Thu, 6 Nov 2014 13:43:57 +0000 Message-ID: <1415281437.2030.1.camel@citrix.com> References: <1415278831-9249-1-git-send-email-ian.campbell@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1415278831-9249-1-git-send-email-ian.campbell@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On Thu, 2014-11-06 at 13:00 +0000, Ian Campbell wrote: > libxl__device_disk_local_initiate_attach is assigning dls->diskpath with a > strdup of the device path. This is then passed to the callback, e.g. > parse_bootloader_result but bootloader_cleanup will not free it. > > Since the callback is within the scope of the (e)gc and therefore doesn't need > to be malloc'd, a gc'd alloc will do. All other assignments to this field use > the gc. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767295 I should really have included the valgrind spew: ==4739== 48 bytes in 2 blocks are definitely lost in loss record 30 of 41 ==4739== at 0x4026B2D: malloc (vg_replace_malloc.c:299) ==4739== by 0x41979FF: strdup (strdup.c:43) ==4739== by 0x4064EC4: libxl__device_disk_local_initiate_attach (libxl.c:3033) ==4739== by 0x4099256: libxl__bootloader_run (libxl_bootloader.c:387) ==4739== by 0x4073CCE: initiate_domain_create (libxl_create.c:915) ==4739== by 0x4073CCE: do_domain_create (libxl_create.c:1513) ==4739== by 0x4073E75: libxl_domain_create_new (libxl_create.c:1536) ==4739== by 0x80578DB: create_domain (xl_cmdimpl.c:2518) ==4739== by 0x805B4B2: main_create (xl_cmdimpl.c:4652) ==4739== by 0x804EAB2: main (xl.c:378)